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ABSTRACT 

Based on telephone interviews with 12 Association of 
Research Libraries (ARL) member libraries, this report presents the 
underlying reasons for the libraries' decisions relating to the 
design and implementation of automated library systems. The survey 
results are summarized, a list of respondents is provided, and 
profiles of present and planned systems are presented. A copy of the 
telephone questionnaire is also included. Primary-source documents 
pertaining to the planning process, implementation, and operation of 
automated library systems are presented as follows: (1) Planning 
Process — "Charge to Automation Committee" (University of Houston), 
"Candidate Systems" (University of Michigan), "NOTIS at Rice 
University" (Rice University), "Committee Appointment Letters" (Ohio 
State University), "Report of the Ad Hoc Cqmmittee on Future 
Information Services" (Texas A&M University), and "Formal Evaluation 
of Vendor Proposals" (Vanderbilt University); (2) 

Implementation — "Implementation and Operation of Linked/Interfaced 
Systems at the Library of the University of Illinois at 
Urbana-Champaign" (University of Illinois); "Operating Environment, 
Development Activities, S-Year Projection" (University of North 
Carolina); and "Implementation Plan** (University of Michigan) ; and 
(3) Operation — "Proposed Service Agreement between the University 
Library System and the Computing Center" (University of Michigan), 
"Agreement Relative to Responsibilities to IBM" (Vanderbilt 
University) , "New 7ork University Libraries GEAC Online Catalog" (New 
York University), and "Use Statistics Survey" (Vanderbilt 
University). (KM) 
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AUTOMATED LIBRARY SYSTEMS IN ARL LIBRARIES 



JL he development and implementation of more fully 
integrated or interfaced automated systems involve a 
series of administrative and technical issues that ultimately 
affect all levels of academic libraiy staff. In addition, the 
environment of automation enhancements is changing 
rapidly, demanding increased ability on the part of the 
library to keep up with technological advances, to remain 
flexible as decisions are made, and to reorganize as 
responsibilities shift. 

The chief purpose of the research leading to this SPEC 
Kit was to discover underlying reasons for decisions as 
automated systems are more fully integrated in Associa- 
tion of Research Libraries (ARL) libraries. Scheduled 
telephone interviews of about two hours duration were 
conducted with representatives of 12 member libraries 
during Spring 1986. Questions covered three broad areas: 
pre-purchase or design decisions, responsibilities for 
system implementation and operation, and expectations 
for the future. The libraries included in the survey were 
selected to represent different approaches to integrated 
automation, namely locally designed systems, vendor 
delivered systems, software-based systems, and systems 
that mixed more than one of these strategies. The first 
document in the Kit provides a complete report on survey 
results. 

PRE-PURCHASE AND DESIGN DECISIONS. Meth- 
odologies that libraries used to select and design auto- 
mated systems were reflective of their general decision- 
making process. In many instances, the decision-making 
was kept at an administrative level, with final choices 
made by the director, or the director in consultation with 
senior level administrators. Libraries often used commit- 
tees, and in a variety of ways— ranging from general 
automation committees overseeing all functions, to ad hoc 
committees writing specifications for specific modules. 



Systems department or officer responsibilities included 
serving as primary authors of locally designed systems or 
Requests For Proposals (RFP),. or as consultants to 
committees. Where there was local development, the 
systems office generally was at the center of nenrly all 
activities, with extensive interaction with operational 
units. (A SPEC Kit detailing systems organizations in 
ARL libraries is scheduled for publication later this year.) 

Although most of those surveyed had not employed 
consultants, their assistance was useful in some areas. 
Consultants provided general and detailed specifications 
for purchase or design, validated the work of other 
consultants, evaluated concepts that had been developed, 
and provided broad systems architectures. 

Major technical decisions faced by the libraries involved 
purchase vs. design of a system, integrated vs. interfaced 
architecture, and whether to base the system on mini- 
computers or mainframes. In each of these areas, the 
reasons for decisions have changed over the past three 
years because of developments in libraiy systems and 
library staff expertise. In all cases of locally designed 
systems, automation efforts were already well underway 
by the end of the 1970s. Integrated systems (the develop- 
ment of a system by a library or vendor as a single 
product) and interfaced systems (the local mixing of 
systems from a variety of sources) have both increased in 
use substantially since a 1983 SPEC Kit addressing this 
same subject. Although the 1986 phone survey discovered 
a few cases of purely integrated and purely interfaced 
systems, there usually was substantial crossover. 

There was a fairly even division between libraries using 
mainframes and minicomputers. When mainframes were 
involved, it was common to have the computer located 
outside the library,. such as in the university computation 
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center. Typically, libraries chose minicomputers to keep 
the staff time devoted to machine maintenance to a 
minimum, and to allow the library to maintain control 
over the system. The key issue in all of these decisions, 
howevcjr, was not based on a superior ?jchitecture. In 
most cases, the architecture was decided based on the 
desired functionality or the available resources, rather 
than the architecture being a goal unto itself. 

OPERATIONAL RESPONSIBILITIES. Library opera- 
tions were typically the purview of the managers of 
individual areas, rather than of committees. Nonetheless, 
some libraries accomplished many changes through com- 
mittees, and in situations where operations were given a 
large degree of autonomy, committees werj considered 
vital to the success of the enterprise. The role of systems 
departments often was to provide project management 
and technical support, including coordinating the hardware 
and software, running jobs, and coordinating a mainte- 
nance contract. Training and documentation was a part of 
both the systems department and the operational depart- 
ments. The systems departments provided initial training 
and documentation on how systems worked, while the 
operational departments were responsible for writing 
procedures and u^ning manuals to integrate the system 
into the workflow of the dqjartment. 

ORGANIZATIONAL CHANGES RELATED TO SYS- 
TEM IMPLEMENTATION. Probably the most significant 
and widespread changes resulting from automation were 
in the reorganization of libraries to accommodate the new 
systems. Many of the observations and predictions in 
SPEC Kit #]]2 (Automation and Reorganization of 
Technical and Public Services, March 1985) were being 
implemented. Libraries reported that organizational re- 
structuring was prevalent, ranging ftx)m the creation of 
new divisions and departments to the establishment of 
new positions to coordinate automation activities. Many 
respondents noted that automation had caused a further 
decentralization of operations because information that 
previously was housed in one place (usually technical 
services) was now distributed to wherever terminals were 
located. This decentralization had brought a vast increase 
in the involvement of public services librarians in the 
automation efforts of the library. Some libraries had 
distributed cataloging or serials check-in to departmental 
libraries. 



NEEDS AND TRENDS. According to the 12 librarians 
interviewed, areas in need of improvement reflect both 
public and technical services concerns: the need for 
additional CPU power; improved design terminals and 
workstations; the availability of user cordial boolean 
operators and keyword searching; better management 
statistics and information; refinements to the public 
access catalog screen displays; widespread availability of 
non -Roman alphabet items in the database; improved 
methods of using Library of Congress authority tapes to 
apdate local authority files; retrospective conversion for 
specific collections or for the entire collection; the 
inclusion of periodical index access through the same 
terminal as the online catalog; and improved vendor 
services. 

The next generation of systems was expected to bring a 
host of changes, many of which were already under 
development. These changes included: expanded data- 
bases, including the information now available from 
online databases and full text retrieval; more links with 
other computing systems on campus through a common 
interface and local area networks; user-based design; 
simplified software; greater use of artificial intelligence to 
create expert systems to assist users; and more sophisti- 
cated workstations that will incorporate audio, video, and 
data communications for scholars. 

This kit serves to update SPEC Kit #90, Integrated 
Library Information Systems, published in January 1983. 
(Kit #90, which remains available as a back issue, 
includes results of a SPEC survey of 31 ARL libraries, 
planning documents, general system descriptions and 
reviews, and examples of specifications.) 

SPEC Kit #126, Automated Library Systems in ARL 
Libraries (July-August 1986, 111 pages), contains SPEC 
survey results, six documents describing the planning 
process, three documents describing implementation of 
systems, and four documents dealing with operational 
issues— two on computer center relationships, one exam- 
ple of use statistics, and one general system description. 

* * * * 

This flyer/kit was prepared by Arnold Hirshon, 
Associate Director for Technical Services and Automation, 
Virginia Commonwealth University, as part of the 
OMS Collaborative Research/Writing Program. 
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USES OF SPEC KITS 



The Systems ond Procedures Exchar^e Center (SPEC) is o 
clearinghouse operated by the Associotion of Research 
librories. Office of Morxagement Studies thot provides o centrol 
source of timely informotion orKJ moteriols on the morxagement 
and operotior^ of targe ocodemic ond research librories. It 
facilitates the exchange of knowledge ond documents through 
SPEC Ki*s. which ore distributed ten times each yeor to ARL 
members and other interested librories. The Kits Irclude 
topicolly-orrortged groupings of unedited prirnory source 
documents - selected for their volue to odminlstrotors ond 
decisbn-rTK3kers - that illustrote o wide ronge of o!terrx3tive op- 
pfoaches to specfic issues. 

Kit documents come from generol membership surveys ond 
from selected librories contocted directly by SPEC, and most 
Kits ore produced within six months of surveys. The documents' 
value comes from their voriety of ideas, methods, ord solutions. 
They ore not viewed os finished products, but rot her as points of 
departure for o librar/s plonrwrg efforts ond os stimulonts to irv 
novotive opprooches to problem-solving. As such. Kits do rtot 
present onswers or prescriptions for ony one librory; instead 
they illustrate how selected ARL members ore plonning for or 
dealing with porticulor Issues. The worth of ony one Kit to a par- 
ticulor librory will depend upon the specific topic covered ond 
the libror/s stoge of development in that oreo. 



Moteriols ore selected occording to the following criterio: 

• Presents on opprooch of iDOtentiol volue to odminlstrotors 
ond decisiorvmokers 

• Timely, ond deoling directly with the topic under corv 
siderotion 

• Probability of opplicotion of ideos or thinkirig to other 
librory situotions 

• lllustrotive of octuol proctica rother thon theoreticol 

• UrKjerstondobla reodoble communication 

All together, the rpoteriols should provide o ronge of olterrx3tive 
approaches that complement each other, provide voriety. ond 
stimulote comfDorison ond controst. 

Librories con toke odvontoge of the Kit compilotions in o 
number of woys. Adnr^r>lstrotors con evoluote the ossumptior^. 
methods, ond results of other librories* opproaches; compoie 
and controst them* ond use the learnings in their own situotions. 
Librory stoff members con use the kits os professional devetar> 
ment orxJ current oworeness tools. Committees orxi tosk forces 
con use them to begin a review of current proctices. And the 
Kits con identify other persons or ploces to contoct for further 
informotioa Back-up files In the SPEC office oisc ore avoiloble 
for loan to member librories. In odditioa SPEC w ll conduct on- 
demond surveys or orralyses geored specif icolly for o sir^gle 
librory. 



EVALUATION 

Kit Title/Number 

1. Wrtch uses did the librory nnoke of this Kit? 



2. Please indicote how useful the Kit wos for these purposes. 

□ Very Useful □ Quite Useful □ Somewhat Useful □ Not Useful 

3. Do you have suggestions for this Kit or for future Kits? 



(optional) NAME ■ 

LIBRARY 

PHONE 

Please return this form to the SPEC Center, OMS/ARL 1527 New Hompshire Ave.. N.W.. Woshingtoa DC 20036. 
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AUTOMATED LIBRARY SYSTEMS IN ARL LIBRARIES 
From RFP To Reality: A Report of Survey Results of Twelve ARL Libraries 



Arnold Hirshon 

Associate Director for Technical Services and Automation 
Virginia Commonwealth University 



The development and implementation of automated library systems in ARL 
libraries involve some of the most challenging administrative and technical 
issues that libraries must address today. The decisions reached, and the 
methodologies employed to reach those decisions, have wide-ranging 
implications that involve all levels of library staff. The environment has 
changed so rapidly that information published only three years ago is already 
very out-of-date. (see also: Integrated Library Information Systems in ARL 
Libraries. Washington, D.C.: Association of Research Libraries, Office of 
Management Studies Systems and Procedures and Exchange Center, 1983 . SPEC 
Kit no. 90.) 

This SPEC Kit is different from most other Kits in its approach. The 
chief interest here primarily was not to represent simply what the ARL 
members as a whole or individually were doing with automated library systems, 
but more importantly, the underlying reasons for the decisions. Telephone 
interviews were conducted with twelve ARL member libraries during the spring 
of 1986. The libraries chosen for the survey and in the documents are 
national leaders in automation and represent different approaches to 
integrated automation: locally designed systems, vendor delivered systems, 
software-based systems (such as NOTTS), and systems that mixed more than one 
of these strategies. 

Through some survey questions, we sought to discover trends; through 
others, provocative ideas. From the information presented, it is hoped that 
a library embarking upon a decision will understand why a library chose the 
course of action, and to judge whether those reasons are applicable to the 
local situation. In most instances throughout the Kit, you will not find the 
typical statistical results as to how many libraries are following a 
particular practice. In this way, the generalizations to be drawn from the 
information presented will come from the reader. 
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1. PRE-PURCHASE/DESi n N DECISIONS 

This section reports the experiences of the libraries concerning the 
methodology used to decide whether to purchase or design, and to introduce, 
the system. 

1.1. Decision Methodology and Assignment of Responsibilities 

The methodology to decide on an automated system was reflective of the 
general decisionmaking process. In many instances, the decision was reached 
by upper level administrators, such as the chief administrative officer of 
the library (director), or the director in consultation with other senior 
level administrators. In some cases this extended as far as a single 
administrator determining, in large measure, the character of the system. 

Although middle management (such as department heads) and other staff 
were included at the design or implementation stages (when their areas of 
operation were affected), they had much less involvement in the choice of the 
systems architecture to be employed. 

Committees were used repeatedly, and in a variety of ways. Most often, 
different types of committees were employed at different stages. Some 
libraries had general automation committees to oversee all functions. In 
other cases there were separate committees, for example, to write 
specifications for a particular module, or to implement a function. 
Committee documents were circulated widely throughout the library for 
comment. Regardless of the library, whenever committees were used, the 
ultimate decision rested with the chief administrative officer of the 
library. 

Libraries that decided to purchase systems generally prepared detailed 
requests for proposals (RFP's). In one case, however, the library 
administration knew it wanted an existing system, and therefore chose to look 
at available systems only rather than writing an RFP. After reviewing the 
available systems, most of the systems were unacceptable. Following this 
review, staff were recruited based on their expertise (not democratically), 
to evaluate the remaining systems. The systems in the final pool were made 
available in the library for extended demonstrations. 

State universities found the state bureacracy was a partner in the 
process. In one instance, a bid was issued, but it had to be resubmitted 
several times because it was the first time an automated library system 
contract was let out in the state, and contracts were being watched 
carefully. The state required to library to drop some specifications on the 
grounds that the bid should be based on functions the vendor had available, 
not upon what the library desired nor upon what the vendor promised but had 
not yet delivered. The SPEC Kit respondent for this library reported that 
the resulting contract was weak, but strong enough to deal with the vendor 
when necessary. 
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A special role was often given to a systems department or officer. For 
example, in the development of a request for proposal, the systems department 
responsibilities in different libraries included: being the primary author of 
the RFP; being a consultant to operational departments or committees; 
preparing an impact statement. For libraries that undertook local 
development, the systems department generally was at the center of nearly all 
the development, and had extensive interaction with the operational units. 

At three libraries with local development, the initiative came from 
faculty or administrators within the university. At one library, a professor 
who found the library public access system too difficult to use developed his 
own prototype of user interface. He was later contracted by the library to 
build and maintain the interface; this individual was also completing a 
reserve system to interface with the online catalog. At another library, the 
developer was a faculty member in electrical engineering department. 

1.1.1. Consultants 

Most of the libraries surveyed did not employ consultants, which might 
have been attributable to the size and breadth of knowledge available at ARL 
libraries. Three libraries used consultants, two of which chose to purchase 
vendor systems, while the third library developed the system locally. 

In the two situations where the vendor systems were selected, one library 
used consultants to provide both general and detailed specifications on how 
to proceed; a second team of consultants was used to validate the work of the 
first team. The other library used a consultant to review specifications the 
library had already prepared. 

The one library that chose local implementation employed consultants to a 
evaluate a concept that the library had already developed. The consultants 
primarily spoke with administrators, middle managers, library committees and 
university data processing personnel. The consultants were also asked to 
provide a broad systems architecture to implement the concept. After the 
system implementation was underway, this library used another consultant to 
review a specific implementation plan for a new module of the system* The 
consultant was used in this case because the librar was tending toward a 
particular solution and wanted confirmation nothing had been overlooked. 

One respondent from a library that did not use a consultant reported the 
library administration had initially negotiated with some consultants, but 
chose not to sign contracts because the administration believed there was 
nothing to be gained. 

1.1.2. Reasons for Purchasing or Designing 

I.I.2.I. Purchased Systems 

The reasons why libraries chose to purchase rather than develop their 
own systems were: the cost of purchase was less than the cost of 
development; the expected complexity of locally designing a system; the 
staffing resources required for local development; and, there were 
acceptable library automation systems already available in the 
marketplace. 
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1.1 •2. 2. Designed Systems 

Libraries that have designed systems largely fell into two categories, 
with some variations. In some libraries, the systems were designed early 
(during the 1960's and 1970's), but later abandoned in favor of new 
technologies available from vendors or software-based systems. In other 
libraries, there was continual upgrading of the local systems to the 
state of the art. In all cases where local design was employed, local 
automation efforts were well underway by the end of the 1970s. 

Libraries chose to design their own systems because no acceptable 
alternatives were available in the marketplace at the time local 
development work began. There were also local reasons for the decision; 
for example, one library was in the process of a major development effort 
for a new building, and capital was available for systems planning. 

A variation on inhouse design was local design of some functions, with 
interfacing of existing external modules for other functions. 
Interfacing involved either minimal or extensive rewriting of the 
external programs. The decision whether to do all local programming, or 
to interface an external module for a specific function, generally 
revolved around the fiscal iraplications, and the availability of a module 
that could do the job and could be interfaced easily. 

1.1.2.3. Change from Designed to Purchased 

Some libraries changed (or were changing) to a second or even third 
system. These libraries had their previous experiences to call upon. 
Change was sometimes required when transaction loads grew and existing 
systems could not meet the needs. In other cases, the library wished to 
change its automation strategy in some way (such as to abandon a 
standalone function and to look for an integrated system). 

One library previously engaged in local development changed to a 
purchased system because of: the library's involvement in collaborative 
endeavors (including membership in the Research Libraries Group); the 
ability of the library to manage an externally provided system; and the 
high cost of maintaining a systems staff. 

1.2. Systems Architecture 

The respondents were asked state why the library choose the system 
architecture that it did. In particular, why did libraries chose integrated 
versus interfaced systems, and mainframe-based versus minicomputer-based 
systems? 

As defined for this survey, integrated systems were purchased from one 
vendor, or designed locally in toto, with all of the functions intended to 
work together as a single system, interfaced systems were brought together 
by the library through a combination of various modules produced by more than 
one vendor or library. 

Although the survey discovered a few cases of purely integrated and 
purely interfaced systems, there was substantial crossover. The crossover 
began when a library took existing functions from its locally produced system 
(such as a module for a public access catalog or circulation) and added a 
module (such as acquisitions or serials control) from another system. 
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There was a fairly even division between libraries surveyed that were 
using mainframes and minicomputers. The definitions of "mainframe" and 
"minicomputers" have been complicated by the technology. Minicomputers 
traditionally were distinguished from mainframes by the amount and type of 
processing power, and the number of peripheral devices (such as terminals) 
that the central processing unit (CPU) could handle. The advent of 
"superminicomputers" has blurred (but not eliminated) the distinction. In 
this survey, the superminicomputers were included in the minicomputer 
category. 

The key issue, however, was not that one architecture was superior. For 
example, one respondent noted that the library preferred to integrate, but 
found it had to interface because of local considerations. In most cases, 
the architecture was decided as a result of the functionality desired or the 
resources available, rather than the architecture being a goal unto itself. 

I.2.2. Integrated Systems 

The respondents who advocated integrated systems did so because of the 
system* s processing efficiency and effectiveness across all of the 
functions. Integrated systems also eliminated hardware and data redundancy 
(and maintenance of both), and therefore were less costly to run. Through 
integration of data, the information needs of staff and library users could 
be met at one place. 

Some libraries used integrated systems as long as the system provided 
what was needed. If, however, a needed function was unavailable, or if the 
module provided was functionally inadequate, libraries indicated a 
willingness to consider standalone or interfaced modules. 

Another library started with local development of an public catalog. 
When no acceptable module for circulation was commercially available to 
interface with the public catalog, the library administration decided to 
continue local development of the circulation model. 

Although interfacing might be more possible now than when local library 
systems were first being developed, integrated systems adherents believed 
interfacing still presented many problems. Those who choose the integration 
route were skeptical that interfaced systems could be made to work with 
little maintenance over a long time. Some respondents who chose integrated 
systems mentioned problems observed in libraries that attempted to interface, 
but could not make the various system pieces work in harmony. One respondent 
noted it was difficult enough to interface the bibliographic utility with 
local systems without having to interface numerous other subsystems. 

A particular pitfall mentioned in interfacing was the "finger pointing" 
it caused. Library staff had to be involved in coordinating hardware and 
software maintenance to avoid having the various parties involved pass off a 
problem as having been caused by someone else. Libraries that optd for 
integration believed this was one way to minimize (if not completely obviate) 
the finger pointing. 

U2.3« Interfaced Systems 

Only three institutions surveyed had a strategy of interfacing. 
Interfacing resulted because there were no commercially avai .able integrated 
systems when the library begain to mount its system. Interfacing also 
allowed the libraries to finance incremental system growth, purchasing each 
module as it was needed, rather than buying the system all at one time. 
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External concerns were also a factor. One state university library was 
required to interface with the public access catalog system used by the state 
system. The state, however, did not intend to provide functions other than 
the public catalog, so each library in the state system had to separately 
develop the other functions on its own. 

One respondent from a library that began with a locally developed 
integrated system, but later interfaced functions, noted the library adopted 
a philosophy to integrate functions needed at all terminals (such as 
bibliographic and holdings data, and on order information), but not 
information of a specialized nature (such as the fiscal data). 

1.2.'J« Mainframe-Based 

Users said they chose mainframe computers because there were no 
minicomputers of sufficient size to meet their system re^.uirements. 
Libraries using mainframe computers generally required the system to handle 
200-400 terminals; one respondent represented a library with a load of only 
150 terminals. 

The responsibility for the daily management of the hardware sometimes 
falls outside the library. Although outside hardware management is not 
limited to mainframe environments, it was more common to have the computer 
outside the library (such as in the university computation center) when a 
mainframe was involved than a minicomputer. Outside management was a benefit 
because the library could call employ the expertise of the computation 
center, and library staff did not need to tend to the machinery at all hours. 

It is also possible to have a mixture of hardware. One respondent noted 
the library was using microcomputers for its public access terminals. The 
microcomputer was used to translate command syntaxes, and worked as a system 
interface to prevent the response time degredation that would occur if the 
load were placed onto the mainframe. The microcomputer was also effective 
because changes to the interfaces were made more quickly and easily. 

Other respondents reported using a combination of mainframes and 
minicomputers. In one case, the mainframe, which was shared by the library 
and other university departments, housed the main database. The mainframe 
generated multiple copies of the database for the public catalog, which was 
mounted on multiple minicomputers. Backup was therefore provided through 
redundant databases; such redundancy would not have been possible if all of 
the functions were run off the mainframe. In this configuration, each type 
of hardware was used for the purpose for which it was designed; the mainframe 
was used for batch processing, and the minicomputer was used for intensive 
online realtime transactions. 

1.2.4. Min i computers-Based 

Typically, minicomputers were chosen to minimize the amount of staff time 
spent on machine maintenance. Minicomputer users believed their systems were 
as powerful, or almost as powerful, as the mainframes. 

Another reason a minicomputer was chosen was to keep control of the 
system within the library. One reporting library chose a minicomputer 
because the university computation center services were too unreliable when 
the system was first selected. This library was beginning to consider a 
replacement system and said neither minicomputers nor mainframes were being 
ruled out this time because the university computing environment had changed 
for the better. If smything, the library was now wary of choosing a 
minicomputer because it might be too small to meet the demands to be placed 
onto the system. 
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2. SYSTEM IMPLEMENTATION AND OPERATION 

Once the system had been selected, the responsibilities for implementing 
the system were vested in different places within the library. Respondents 
wore asked to address which types of responsibilities were given to 
committees, operational departments (such as the circulation or cataloging 
department), and the systems department, and why this structure was derived. 

2.1. Areas of Responsibility 

2.1.1. Use of Committees 

All the libraries reporting used committees in some capacity, but there 
were widely divergent models how, when and why committees were employed. 
Committees were used to coordinate suggestions for changes to the system, for 
recommending courses of action, and for placing the needs into a priority 
order. Respondents gave the following reasons for using committees: 

- the lack of sufficient systems staff to do all necessary work; 

- the need to collect information from disparate sources on how the 
system should function; 

- to build staff interest in the project and have staff become more 
heavily invested in the decisions reached; 

- to counteract myopic views of operational departments, and to provide 
opportunities for operational departments to go beyond their existing 
base of knowledge by learning and trying new techniques; 

- to act as a buffer for the systems department and prevent systems 
staff from being inundated by trivial requests. 

On the negative side, respondents found cqmmittees time consuming, and 
committees sometimes encroached upon the managerial prerogatives of some of 
the operational departments. At an extreme, one respondent reported the 
library had a general .management philosophy that things were more rapidly 
accomplished by an individual than by a committee. 

Committees were often used in the planning process in the preparation of 
the RFP, in reviewing the responses, in the pre-implementation stages for 
development of new policies and procedures, in initial training, in 
developing brochures and manuals, and in coordinating publicity efforts. 
Libraries with locally designed systems generally relied heavily upon 
committees. 

The membership on committees varied widely, from senior level management 
to line personnel. it also was not uncommon to have representation from 
outside the library to provide technical guidance, such as participation from 
the university computation center. 

Committees were either established as standing committees or were 
disbanded shortly after the initial implementation had been completed . 
Libraries chose the latter strategy to return control quickly to the 
operational department responsible for the function. 

The survey did not reveal a pattern of libraries having a central 
automation coordinating committee; these tasks seemed to be delegated to 
specialized committees and to the departments. 
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Ad hoc committees had broad areas of responsibilities, including the 
preparation of specifications. These committees were also responsible to 
make more limited recommendations, such as the placement of terminals, the 
preparation of needed documentation, and the coordination of training 
sessions. 

2.I.2. Operational Department Responsibilities 

Library operations were typically the purview of the managers of 
individual areas , rather than of committees. Although some libraries 
accomplished changes through committees, departments normally were given a 
wide latitute to manage their own operations. Although the library 
administration wanted middle managers involved , the middle managers 
themselves often saw this as an additional burden. Department heads, senior 
administrators, appropriate committees, or the systems department were 
responsible for resolving issues that crossed over areas of responsibility. 

In operational areas, libraries tend to keep operational control within 
the traditional areas of service. For example, one library noted the 
associate university librarian for public services was responsible for 
convening the design group responsible for suggesting changes the public 
access catalog. In this way, changes emanate from within the departments, 
with an interactive process between the operational and systems departments. 

There was a wide disparity in the involvement of senior level 
administrators in the design and running of the systems. V/hile some 
respondents noted that many or all senior administrators were heavily 
involved in the system policy issues, in at least three libraries, associate 
directors/assistant university librarian level activity was largely limited 
to the "traditional" (non-system) concerns. The chief administrative 
officers as a group, however, exhibited a substantial degree of control over 
systems decisions. 

2.K3. Systems Department and Operational Department Relationships 

The systems department provided project management and technical support, 
including coordinating the hardware and software, running jobs, etc. 
Software and hardware bugs were reported to the systems department by 
librarians using the various system modules. Maintenance contracts were 
coordinated by systems staff as well. 

To make changes to the system, the most common path was to have line 
managers and department heads raise the issue with senior level 
administrators. The administrators brought these suggestion to the systems 
department through either the chief administrative officer or the 
administrative council of the library. As one respondent stated, "[the] 
systems [department] is the guarantor of the project, not the governor." 

Respondents were asked to explain the distinction between the areas of 
responsibility between the systems department and the operational 
departments. In general, the operational departments were responsible for 
creating and maintaining data, and for direct patron interactions. The 
systems department was responsible for making the system run, for setting 
technical standards, and for providing information and support to the 
operational departments. 
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Training and documentation was an area where both the systems department 
and the operational departments tended to be involved. In at least two 
libraries, the systems department provided initial training and documentation 
on how the system worked, but. the operational departments were responsible 
for writing procedures and training manuals to integrate the system into the 
workflow of the departments. After an initial group of staff had been 
trained, it was most common for the operational departments to be responsible 
for the ongoing training (to train new staff and update existing staff). 

2.2. Changes Caused by System iroplementatlon 

The respondents, who came from diverse positions within their libraries, 
were asked to explain what major changes had occurred as a result of 
implementing the system. Both personal opinions as well as organizational 
positions were solicited, but were not isolated. Most of the changes 
reported by libraries affected the staff more than the patrons. 

2.2.1* Organizational Changes 

Probably the most significant and widespread change was reorganization to 
accommodate the new systems, including the creation and use of additional 
committees. At least two libraries reported nearly constant organizational 
restructuring. The nature of these organizational changes, however, was 
quite different. One library reorganized from the top down, creating new 
divisions and departments. In other libraries, new positions were identified 
and created to coordinate automation activities and were added within the 
existing structure. 

Most libraries that previously did not have systems officers or 
departments created them. On the operational side, library positions were 
created to coordinate staff activities such as bibliographic maintenance, 
public catalog training, etc. Some of these positions were fulltime, others 
were a shared responsibility along with other duties. As these positions 
were created, it was common for them to report to the chief administrative 
officer of the library (at least for the automation aspects of the job). 

Automation also had an effect on clerical and paraprof essional staff. 
Job descriptions and ranking structures underwent a review as the result of a 
general library, state, or university review of positions. The result often 
was new classification levels were created because of automation, with an 
increase in the number of paraprof essional levels. 

2.2.2. Decentralization of Functions and Data 

Many respondents noted automation already had caused a further 
decentralization of operations; information previously housed in one place 
(usually technical services) was now distributed to wherever a terminal was 
located. One respondent noted the library was trying to find ways to 
deceri:r^t*U2fc; the work, but to centralize the decisions. 

Y,.^ .iustification for decentralization was to maximize limited staff 
resources; one library expected decentralization to reduce operating costs by 
$500,000 through the reduction of redundant efforts. With decentralization, 
however, was concern that quality standards would drop as less control could 
be exerted over the staff performing these functions. Greater coordination 
of efforts, and more training, were expected to be required in the future. 
One library created a specialized unit for data administration. The unit was 
empowered to enforce its policies through the suspension the privileges of 
units that did not obey the rules. 
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With the decentralization of databases and information there was an 
increased interdependence between the operational areas of the library. Some 
libraries created new committees, and in most cases, supervisors coordinated 
their efforts more. One library noted some staff have "talked to each other 
for the first time." 

Traditional lines were broken. Public services librarians were more 
involved in library automation as a result of decentralization. One library 
disbanded and distributed its central cataloging unit, and now has the work 
performed in departmental libraries. Other libraries were in the midst of 
considering options, including the distribution of responsibilities for 
placement of orders and the check-in of serials. (See also: Automation and 
Reorganization of Technical and Public Services. Washington, D.C. : 

Association of Research Libraries, Office of Management Studies Systems and 
Procedures Exchange Center, 1985. SPEC Kit no. 112.) 

The increased activity by public services librarians brought other 
changes as well, including greater concern about the content of the 
database. Public services staff had to answer more technical questions from 
patrons. The staff had to better understand matters that previously could 
have been ignored, such as the best way to construct search, or the 
significance of MARC tags. Increased expectations of public services 
librarians came with their increased profile in the areas of library 
automation. 

Decentralization was not all positive. Territoriality remained an issue, 
albeit in a different form. For example, one library reported tension during 
the Initial planning and implementation over relatively minor issues, such as 
who would be responsible for the oare and feeding of public access catalog 
terminals and equipment. These problem were solved later, however, as new 
ideas were discussed for coping with the realities of the distributed access 
environment. 



2.2.3. Changes to Policies and Procedures 

Increased attention to the maintenance of the database, and diminished 
concentration on card files, was a policy change mentioned by a few 
respondents. Libraries had even considered elimination of some traditional 
library tools once considered inviolate, such as the shelflist. (See also: 
Catalog Maintenance Online in ARL Libraries. Washington, D.C: Association 
of Research Libraries, Office of Management Studies Systems and Procedures 
Exchange Center, 1985. SPEC Kit no. 119.) Nonetheless, there seemed to be 
few changes to specific policies or procedures that arose from the 
implementation effort. One respondent expressed disappointment that fewer 
changes were made than necessary. Another noted some procedures changed, but 
policies had not. Concern was expressed that there was a lost opportunity to 
use automation as a catalyst for changes that would have resulted in better 
use of the systems. 

2.2.4. Technological (Hardware/Software Related) Changes 

The rapid growth of systems brought an unexpected demand by patrons for 
more services. For example, one librarian noted patrons were asking for 
dial-in access nearly as soon as public access catalog terminals were 
installed. Other services requested were direct access to texts through the 
terminal, printers attached to terminals, remote charging of volumes, access 
to location information, and charging of materials via telephone or the 
computer. 
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2.3. Automation Needs; Realities and the Meal 

The state of automation in the libraries surveyed varied widely. All of 
the libraries had automated at least one or two functions, but some had more 
modules available than others. The respondents were therefore asked to 
address two questions: 

1 . What function has the most and least pressing actual need for 
automation in your library at the present time, and why? 

2. Given what you know about the needs of your library, if no functions 
were automated, how would you personally rank the ideal order in which 
the functions should be implemented? 

2.3.1. Reality 

The highest function ranked was the online public catalog. Some 
libraries included within this function the creation and maintenance of the 
database. The reasons for this high ranking included: the need for 
distributed access to information on a campus that was geographically 
dispersed; the high degree of interest in the catalog expressed throughout 
the university community; the format of the catalog (cards or microfiche) was 
hard to use and had met with resistance by the public; the high visibility 
the library received from catalog implementation; and the elimination of 
redundant technical services operations. 

Serials control also ranked highly because it was becoming harder to 
maintain the large number of active titles in a manual system. Also 
mentioned was the need for distributed access to serials information. Some 
respondents noted library users had increasing expectations from library 
automation, including a need for more serials information. 

Lower ranking functions included circulation and acquisitions. 
Circulation was low on the list primarily because so many libraries had 
automated it, some libraries having done so many years ago. Acquisitions was 
low because present systems were adequate or because no one in the library 
pressed for this function to move up in the queue. 

2.3.2. Ideal 

The librarians who were personally ranking the ideal order for 
implementing systems were asked to address five functions: circulation, 
acquisitions, serials control, public access, and bibliographic maintenance, 
personal responses were expected to be, and were, affected by the positions 
the respondents held in the organization. There were five individuals at the 
associate director/ AUL level for systems; two associate director s/AULs for 
technical services or technical services and automation; two positions in 
general library administration (assistant director for Budget, Systems and 
planning, and associate director of University Libraries); and three 
positions where there was coordination of one or more functions of the 
systems from the operational side (coordinator for Online Catalog User 
Services; head of the Reference Department; and head of the Circulation 
Division and Library Automation Coordinator). (A list of the respondents, 
institutions, and their job titles appears at the end of this report.) 
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As with the "reality" question, the two highest ranking ideal functions 
were the public catalog, and bibliographic database creation and 
maintenance. Reasons for this high ranking were largely the same as those 
given above, such as the impact upon library users. In addition, respondents 
noted the traditional view of the library, with the catalog at the center, 
remained the same in the autorrated environment, particularly because other 
functions (such as circulation) could be run with the same data as the 
catalog. A few respondents stressed the importance of not only creating a 

database, but creating a clean database. One librarian highlighted the need 
for subject access, because that was how undergraduates approach a topic. On 
the practical side, one administrator placed this function highest because it 
was a highly visible item that could be used to justify the expense to the 
university community. 

The next highest function was circulation. One reason for its high 
placement was that knowledge of the availability of the material in the 
public catalog was as important as knovring what the library owns. Another 
respondent noted that access by the users to the online circulation system 
data could help to make patrons less afraid when subject access became 
available in the public catalog, or when the card catalogs were removed. A 
public services librarian noted he would have preferred to redesign authority 
and bibliographic records before converting circulation records because both 
cataloging staff and the public catalog users would have benefitted from the 
presence of cross references not now available in the catalog. Another 
librarian noted that by having circulation follow the catalog, data 
integration problems could be avoided. Finally, one administrator observed 
circulation would be a lower priority because the library had a small user 
population, and automation of circulation might not be needed at all. 

The fourth function mentioned wac acquisitions. The importance of the 
function was to provide on order information to users of the public catalog. 
It ranked lower on the list, however, because it was seen as less necessary 
for the users to know the item was on order than to know what the library the 
library already owned or had available. Other respondents stated automation 
of acquisitions provided more advantages to the library staff than to users. 
Those who would have placed acquisitions higher on the list said automating 
acquisitions was necessary to keep up with the ordering of the large quantity 
of material required by a research library. 

The last function on the ideal list was serials control. On a five point 
scale, only one library rated the importance of this function higher than the 
midpoint (two libraries); all others rated it as as the lowest function (six 
libraries; three not reporting). This low rating was based on factors as 
diverse as a personal predilection for monographs over serials to the 
magnitude and cost of the conversion task of serials. One librarian, who 
placed it lower than acquisitions, did so because serials check-in relied on 
the order process and therefore logically came after it. Another respondent 
gave a pragmatic reason for this low ranking: the library had not yet 
automated the function, and thus there was experience to show the library 
could survive without it. 

2.4. Alterations Heeded to Present Systems 

An element to the management of an automated system was the recognition 
that there were always aspects that staff would like to see changed. 
Respondents were therefore asked what would be changed if anything about the 
present system could be improved. 
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2.4.1. Hardware Concerns 

Two respondents noted the need for additional CPU power, and one noted 
the procedure to batch process, backup and restore the database required too 
much time. As to terminals, some respondents wanted changes to the 
workstations, such as an IBM compatible terminal specifically designed for 
public use in a research library, and a scholarly workstation — a single 
terminal to provide access, through a single command structure, to all data 
from the bibliographic utility, the local system, and external databases, 
along with features such as word processing, etc, 

2.4.2. Software and Functionality Concerns 

One of the most common requests was for the system design to be completed 
and for all functions to be available. Also desired were improvements in 
options for searching, such as: the need for user cordial boolean operators 
and keyword searching; the ability to limit a search by format, location, 
etc; and, the indexing of headings in upper and lowercase. 

Other features mentioned were: improved methods for printing the results 
of public catalog searches; better management statistics and information 
(such as analysis of holdings and growth of collections by classification, by 
what was cataloged, and by the quality of the cataloging); use of a high 
level programming language for the software (rather than assembler); 
realtime, online bibliographic transfer with direct loading of information 
from the utility to local system; a multi-leveled accounting system for 
acquisitions, including listing of sub- funds and manipulatation of data 
rather than having to set up absolute funds); interfaces provided for other 
systems within the university; improved wording of help screens; prompting 
users with suggestions on what to do when a search doesn't retrieve any 
items; and refinements to the public access catalog screen displays, 

2.4.3. Database Concerns 

Staff wanted to see improvements to the existing databases, including to 
have non-Roman alphabets reflected in the system on a more widespread basis, 
and to use (or better employ) Library of Congress authority tapes to update 
the local authority file. Better integration of data across functions was 
mentioned by some libraries that had interfaced functions. 

Libraries wanted enhancements to databases as well. In addition to 
retrospective conversion . for specific collections or for the entire 
collection, libraries were also exploring ways to include periodical index 
access through the same terminal as the online catalog. This was possible by 
purchasing tapes to load into the local system, by using laser storage 
technology, or or by creating an interface/gateway into existing databases. 
Another idea was the creation of an online library resources directory that 
would integrate uncataloged materials into the public catalog, such as 
vertical files and planning documents, 

2.4.5« Vendors 

Libraries also wanted to see improvements in the services provided by the 
systems vendors. Some problems mentioned were unreliable vendor maintenance 
services, and the need to improve system and user documentation. 
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3. FUTURE TRENDS 

in this last section, the respondents were asked to project the future of 
their systems, the difference of automation changes from other types of 
changes that have occurred in libraries, and what directions systems take in 
the future. 

3.1. Life Expectancy of Hardware and Software 

The respondents were first asked to predict how long they expected the 
present hardware and software would last before having to substantially 
upgrade it or replace it. In addition, the respondents were asked if there 
were any plans in the library for financing the replacements or upgrades. 

3.1.1. Hardware 

Two of the libraries were in the process of substantially upgrading 
central processing units. Half of the respondents expectated the CPU would 
last from two to five years without replacement or upgrade. Some indicated 
routine upgrading would be considered a normal part of the system operation. 

3.1.2. Software 

For this question, respondents were asked about replacement of the 
software or upgrading to a "new generation" of software. A new generation was 
distinguished from evolutionary upgrades. Evolutionary changes would occur 
through new releases of software; new generations would encompass substantial 
changes that resulted either in a new version or system that had far greater 
functionality than was previously available. 

Despite this definition, many libraries continued to believe evolutionary 
changes would accommodate their needs indefinitely, and there was no 
expectation a whole new system would be needed. One respondent expected the 
library would stay with the present system vendor, and any change would depend 
upon what the vendor had in store. 

Of those that did project a length of time, four respondents said upgrade 
or replacement would occur within five years, two said within seven to ten 
years, and one said within ten to fifteen years. 

3.1.3 Financing 

When upgrading or replacement of hardware or software became necessary, 
financing was expected to be done through: funding by the university as 
special appropriation; grants from outside the University; payments to the 
computation center from the library operating budget; and, loans with 
repayment from the operating budget. 
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3.2. I3 Automation Different? 

Three quarters of the respondents thought the implementation and operation 
of automated systems was different from the implementation of other types of 
changes in the library. Some observed automation implementation was 
particularly different when automation was first being introduced, but the 
lessons learned from automation had been assimilated into the general 
management of all changes in the library. Examples of such assimilation 
included the use of project management and the use of committees. 

Profound effects both outside and inside the library were attributed to 
automation. Automation changes required more involvement from outside 
administrators or offices of the university. Inside, automation affected 
every position level in the organization. Although committees working in 
non-automation areas could come and go without ever signficantly affecting an 
individual's job, automation committees affected many jobs. 

As the outside and inside decisions were merged , automation required 
library staff to have more specialized job knowledge. Decisions were more 
"public." For example, with non-automation decisions, the library often could 
make a decision in an insulated environment. If the university, however, had 
to make a substantial financial investment in automation, it was necessary for 
the library to meet the standards of other computer experts in the University, 

On an individual level, automation was different in the level of anxiety 
it produced. At first, automation caused staff to feel threatened by the 
change, however one respondent reported staff, were beginning to see the 
prospects of automation as exciting. 

One respondent stated that although staff thought automation changes were 
different, the changes really should not be different. The higher risk of 
failure, or the technical complexities, have given automation changes a false 
mystique. One respondent believed the root cause for the perception that 
automation changes were dufferent was that librarians were not trained to be 
managers and make decisions, and it was the decisions that should be 
concentrated upon, not the automation itself. 

3.3. Automated Library Systems; The Next Generation 

The final question was blue sky: what will or should the next generation 
of systems have that the present generation does not? The survey did not 
limit the respondents in any way, and so it is interesting to note that the 
responses tended to formulated upon technology that is either available at 
present or is clearly under development. Not surprisingly, many of the 
changes that libraries were seeking to their present systems in section 2.4 
above reappeared in this section as well. Future systems, therefore, were 
seen within the context of the next five to ten years. No one predicted am 
end to libraries nor to information systems. 

Based upon the respondents comments, and the observations of the author, 
it is possible to provide a composite view of the future. 
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3. 3.1. Expanded Dafcabases and Services 

Many respondents noted future systems will make more information and 
databases available, especially data that is not part of the typically 
monographic control upon which our present public access catalogs are 
premised. Information resources will be merged into a single access tool, 
including not only serials, microform sets and retrospective materials, but 
also the the information now available from online databases (such as BRS and 
Dialog). Full text retrieval and universal indexing are also anticipated. 

This expanded access will be possible through a variety of means, 
including intelligent interfaces between the local catalog and the external 
services, or through the loading of portions of these databases into the local 
systems. Even small local files may become practical to load into the system; 
the "shoebox" file of slide collections, technical reports, and the campus or 
city newspaper, may all be part of the information system. 

3.3*2. Workstations 

A few respondents mentioned that we will see more sophisticated 
workstations for staff and patrons. The workstation concept will allow users 
to reach out beyond institutional walls. Audio, video and data communications 
will be incorporatv^d into a single access system. This will provide scholars 
with the opportunity to retrieve from different databases on different 
windows, and edit the data into a cohesive text. 

3.3«3« System Design and User Friendliness 

The basis of the system will gradually begin to change. Future systems 
will be extremely user friendly and will be built upon the public access 
system for the benefit of the users. With a user-based design, library 
specific terminology, search strategies and screen formats will be minimized 
or eliminated, and the system would require no training for use. 

Operationally, systems will allow a great deal of flexibility. A 
nonprogrammer will be able to set up software and easily select options. 
Software will be as easy and flexible to use as a microcomputer database 
management system. Artificial intelligence and expert systems will be part of 
the system design, and will assist library users by predicting their needs. 
For example, the system may help to develop search strategies and assist users 
in developing a topic into a paper, and automatically provide the gateway to 
external services. 

3.3»4. Decentralization; Access and Management 

In addition to linking to outside databases, there will be further 
development of linkages with other computing systems on campus, available 
through a common interface. Some libraries reported these services are 
already available through their university computing systems. Changes in 
hardware and software (through local and broad area networks) will make these 
developments increasingly sophisticated. 
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Decentralization will also allow libraries to alter internal management, 
moving away from centralized management and staffing, and distributing work 
geographically around buildings on campus. Local area networks will become 
prominent since the systems architecture will no longer require mass storage 
at a central site with commensurate high telecommunications costs. Libraries 
will have to continue to develop protocols to link local and external systems, 
and this will cause libraries ultimately to move toward the concept of being 
an information center, with the library having the opportunity to be the 
central node to bring departmental and individual files together. 



n. OBSERVATIONS OF THE AUTHOR 

Automated library systems have come a long way since the 1960s, when the 
first batch mode circulation systems were introduced. Even since the early 
1980s, many libraries have moved from the RFP stage to actual implementation, 
and have gained experience with systems. In the 1960s and 1970s, we looked at 
automation as a way to solve problems of internal operating efficiency, and 
later, to provide improved user access. For the most part, however, 
automation was used as a sophisticed tool to performed traditional library 
functions. 

The trend for the latter 1980s and 1990s will be for the library 
automation to merge into the larger environment of information management and 
communications, both within each university as well as the nation. It is 
unlikely at the turn of the century that we will see separate library systems 
as we have now,. Systems will be highly interconnected, and the databases 
that we have today may well become so "enriched" that their roots may be 
uncrecognizable. The systems certainly will not continue to appear as a 
series of unconnected systems with gateways, but rather will have far more 
integration. The library will be incorporated into a much larger information 
infrastructure within the university, and the organization of library 
functions will doubtless be based upon user needs, such as instruction and 
research, and not upon internal functions. 

Much of the experience that we have gained with automation can serve us 
well if we incorporate the best of the lessons that the past has to offer. 
This Kit has attempted to start us in that direction. The future for 
automation will be the same as the past in one major respect: there will be no 
correct choices, only options and trade-offs. Choosing wisely will 
undoubtedly be the biggest challenge of all. 
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Columbia 
Illinois 
Hichigan 
New York Univ, 
North Carolina 
Northwestern 
Ohio State 
Rice 

Texas A 4 M 



BLIS 

LCS 

NOTIS 

GEAC 

TRLN 

NOTIS 

LCS 

NOTIS 

unknown 



Virginia Polytechnic,. VTLS 
Wisconsin Local 



OCLC, RLIN 
RLIN, NYSILL 
OCLC, LCS 
RLIN, NOTIS 
RLIN, NYSILL 
OCLC, TRLN 
llOTIS, RLIN 
OCLC 
OCLC 
OCLC 
OCLC 
OCLC 



GLADIS 
BLIS 
LCS 
NOTIS 

GEAC, RLIN 

TRLN 

NOTIS 

Innovacq 

NOTIS 

unknown 

VTLS 

NOTIS 



GLADIS 
BLIS? 



GLADIS/Helvyl GLADIS 



BLIS 



unknown LCS/WLN 

NOTIS NOTIS 

GEAC GEAC 

TRLN TRLN 

NOTIS NOTIS 

Innovacq LCS 

NOTIS NOTIS 

unknown unknown 

VTLS VTLS 

NOTIS NLS 



BLIS 

LCS/WLN 

NOTIS 

GEAC 

TRLN 

HOTIS, RLIN 

LCS 

NOTIS 

unknown 

VTLS 

NLS 



Interface to GLADIS 
PCs; interface to BLIS 
Interface to LCS 
Interface to NOTIS 
Interface with GEAC 
TeriDinals/PCs 
Interface to NOTIS 
Interface with LCS 
Possible interface 
Terminals/PCs 
Interface to CD-ROH 
Possible interface 



Key to Terms: 

Bibliotechniques (vendor produced system) 

Vendor produced integrated system 
DataPhase vendor produced integrated system 

^^^^ Vendor produced integrated system 

GLADIS Local system for the University of California, Berkeley 

Innovacq innovative Interfaces acquisitions system (vendor produced) 

LCS Library Control System (Ohio State); Library Computer System (Uinois) 

System was based upon the original design at Ohio State 
^'^^^^ System was bcally designed 

Helvyl union public, catalog for the University of California system (all campuses) 

jrthwestern system (software-based) 

University of Wisconsin local system 
NYSILL New York State Interlibrary Loan system 

°('LC Online Computer Library System 

J";?" Research Libraries Information Network 

WIS r'?!' iTu. ^'^'''^ ^^'^'^ °^ ^''^^ Carolina, North Carolina State U.) 

•'^-^ Virginia Tech Library System 
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PROFILE: PLiM SOT TO BE USED BY LIBRARIES INCLUDED IN THE SURVEY 



LIBRARY 


CIRCULATION INTERLIBRARY ACQUISITIONS SERIALS PUBLIC 


BIBLIOGRAPHIC 


DATABASES 






LOAN 


CATALOG 


HAINTENANCE 




California (Berkeley) Local 


OCLC, RLIN GLADIS 


GLADIS GLADIS/Helvyl GLADIS 


Interface to GLADIS 


Columbia 


BLIS 


RLIN, NYSILL BLIS 


BLIS? BLIS 


BLIS 


PCs; interface to BLIS 


Illinois 


LCS 


OCLC, LCS LCS 


unknown LCS/WLN 


LCS/WLN 


Interface to LCS 


Hichigan 


NOTIS 


RLIN, NOTIS NOTIS 


NOTIS NOTIS 


NOTIS 


Interface to NOTIS 


New York Univ. 


GEAC 


RLIN, NYSILL GEAC, RLIN 


GEAC GEAC 


GEAC 


Interface with GEAC 


North Carolina 


TRLN 


OCLC, TRLN TRLN 


TRLN TRLN 


TRLN 


Terminals/PCs 


Northwestern 


NOTIS 


NOTIS, RLIN NOTIS 


NOTIS NOTIS 


NOTIS, RLIN 


Interface to NOTIS 


Ohio State 


LCS 


OCLC Innovacq 


Innovacq LCS 


LCS 


Interface with LCS 


Rice 


NOTIS 


OCLC NOTIS 


NOTIS NOTIS 


NOTIS 


Possible interface 


Texas A & H 


unknown 


OCLC unknown 


unknown unknown 


unknown 


Terminals/PCs 


Virginia Polytechnic,. VTLS 


OCLC VTLS 


VTLS VTLS 


VTLS 


Interface to CD-ROH 


Wisconsin 


Local 


OCLC NOTIS 


NOTIS NLS 


,NLS 


Possible interface 



Key to Terras; 




BLIS 


Bibliotechniques (vendor produced systew) 


CLSI 


Vendor produced integrated system 


DataPhase 


Vendor produced integrated system 


GEAC 


Vendor produced integrated system 


GLADIS 


Local system for the University of California, Berkeley 


Innovacq 


Innovative Interfaces acquisitions system (vendor produced) 


LCS 


Library Control System (Ohio State); Library Computer System (Uinois) 




System was based upon the original design at Ohio State 


Local 


System was locally designed 


Helvyl 


Union public catalog for the Universit of California systeoi (all campuses) 


NOTIS 


Northwestern system (software-based) 


NLS 


University of Wisconsin local system 


NYSILL 


New York State Interlibrary Loan system I ; 


OCLC 


Online Computer Library System 


RLIN 


Research Libraries Information Network 


-TRLN 


Triangle Research Libraries Network (Duke, U, of North Carolina, North Carolina State U.) 


iVTLS 


Virginia Tech Library System 
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APPENDIX: SPEC TELEPHONE QUESTIONNAIRE 

In ?,n3werins the questions below, if different answers are necessary for 
different functions, please answer the question in general terms, with 
examples from vav^Jous functions, 

LIBRARY PROFILE 

To analyse in context the responses to the questionnaire, it is helpful to 
know the name of the actual systems that are planned or are in use. Please 
provide a quick statement about each of the functions listed below^^ including 
the approximate number of terminals assigned to each function. 

1 . Circulation 

2. ILL 

3. Acquisitions 

4. Serials Control 

5. Public Catalog 

6. Bib Maintenance 

7. Database searching 

8. Other 



PRE-PURCHASE/DESIGN DECISIONS 

1. What methodology was employed : 

a. to decide whether to purchase or to design a system, 

b. to planning for the introduction of the system 

1. RFP and negotiations with: university, staff, vendor 

2. Contract and negotiations with: university, staff, vendor 

In particular, was a consultant employed? If so, what was the consultant 
exoected to do, and why were those responsibilities assigned to the 
consultant? What responsibilities were assigned to which position(s) in 
the library primarily for each of these stages, and why was that position 
chosen? 

2. What were the dominant reasons behind choosing the architecture that you 
did: 

a. integrated versus interfaced systems 

b. mainframe based versus minicomputer based. 

SYSTEM IMPLEMENTATION AND OPERATION 

3. In implementing the system, where and why were responsibilities vested for 
systems and operations? Which types of responsibilities were vested in 
committees, departments or individuals, and why this structure was 
derived? Which position(s) had general ongoing responsibility for the 
coordination of changes required by implementation? (If this 
responsibility is decentralized to a few key positions for different 
functions, please identify the functions and positions.) 



EKLC 



SURVEY 



7. 



8. 



9. 
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a. Were major changes accomplished as a part of implementing the system? 

b. What expected and unexpected changes occurred to policies and 
procedures as a result of the automation process? 

c. Were there more of the former or the latter? 

Reality versus the Ideal: 

a. Reality: What function has the most pressing need for automation in 
your library at the present time, and why? Which one has the least 
need, and why? 

b. Ideal: If you could personally set the ideal priorities for automating 
library functions in your library, which functions would be automated 
first, and why? 

If you could change anything about your present system (e.g., any feature, 
function, design specification, documentation, etc), what would be the 
top five changes you would make, and why? 



a. How long do you expect your present hardware will last before having 
to replace it? How do you expect to plan for and finance the 
replacement? 

b. How long do you expect your present software will last before you would 
need to upgrade to a newer generation of software? How do you expect 
to plan for and finance the replacement? 

Has the implementation and operation of automated systems been different 
from the implementation of other types of changes in the library? (For 
example, in the use of committees, consultants, or the establishment of 
coordination responsibilities for certain activities outside of the normal 
organizational hierarchy.) If so, please explain. 

What do you think the next generation of systems should have that the 
present generation does not? What features would you most like to see in 
your current system? 



FUTURE 




System and Procedures Exchange Center 



Planning Process 
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AD HOC AUTOMATION COMMITTEE 
August 21, 1981 

The revised charge to the Committee is to prepare a plan for automating the 
University of Houston Libraries within the next five-ten years. This plan 
should include the following: 

1. A list of the reasons why the Libraries wants or needs to automate. 
The benefits of automation, 

2. A list of guiding principles or general requirements for automation 
within the Libraries, in priority order. 

3. A list of the functions/activities to be automated, organized into 
natural groupings (modules or subsystems). Functions within the 
groupings should be in priority order, and the subsystems themselves 
should be assigned a priority. 

4. A list of specifications/requirements for each subsystem to be 
implemented. 

5. An estimate of the costs of the proposed automation. 

6. An exploration of the alternatives to implementing the proprosed 
plan, with a recommendation as to the best. 

7. A general strategy for implementing the plan, including: 

a. An outline of the steps or phases necessary to complete tho 
project. 

b. A project schedule. 

c. How the automation will be financed. 

Once this plan has been completed, the following steps will be necessary: 

1. Distribute the preliminary plan widely, ask for input, and conduct 
hearings.. 

2. Incorporate staff input into the plan. 

3. Present the plan to Mr. Downes for approval. 
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DRAFT 



ILS ADVISORY COMMITTEE 
SUBCOMMITTEE ON BIBLIOGRAPHIC QUALITY CONTROL 



CHARGE ; To develop effective and consistent bibliographic control procedures 
for the ILS in order (1) to ensure the creation and maintenance of a 
high quality data base and (2) to resolve any problems that result 
from the attempt to integrate bibliographic records from five 

cataloging agencies into the ILS. This subcommittee shall meet quarterly 
or as the need arises. 



MEMBERS : Linda Thompson, Chair 
Virginia Davis 
Charlene Jones (or designee) 
Ann Kimzey (or designee) 
Virginia Allen (or designee) 
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The Research Library Group's (RLG) CarnnK^ SAydv_oiL..Pl.^^^^^^ 
Processing surveyed and evaluated librarv aul.omaLion packages. While 
no single systcem was found to support all functions n«€?ded bv 
Michigan and other RLG member libraries, thref? ?5v<Lt I:em3 , Ge^^c , BLI3, 
and NDTIS, were judged acceptable and likely to be substantially 
enhanced. 

Geac is a Canadian company and is a leadina force in the market- 
Their system is based on propr'ietary hardware and software. The 
system supports all functions (serials control is in te?st). Geac: is 
the vendor of the Library's exi'sting circulation systum. HawM>ver , we 
have rtjjected Geac from further consi der-a ti on for four reaEon^b^. First, 
Geac's use of proprietar-y hardware and software results in an 
extremely closed system. Second, the system is not truly integrated. 
Circulation and the online catalog, for example, use different 
databases that must be synchronised, a task most sites have found 
difficult to accomplish. Third, there is doubt whether Geac can 
provide a system that can support AGO concurrent users. And fourth, 
because of substantial grov\«th over the last two years the quality of 
Geac's technical support has deteriorated: this is especially 
disturbing given tlie proprietary nature of tl»e system. 

BLIS is based on software developed by the Washington Library 
Network (WLN) and is marketed by Biblio-Techniques-. BLIS runs on IBM 
machines under VN and MVS. ADABAS is used as the DBMS and CQM-PLETE 
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is the teleprocesBinq monitor. Samp usq is {\)r^Llt^ of NATURAL but moE»t of 
the code? is in PL/1. Tlui! system 'supports ?\n online catalog, 
acquisitions, and record maintenance. Circulation is under 
developmc?nt and is schwduUud far delivery e?arly in 19136. Serials 
control is scl^eduled to be available earl.v in 19B7. We believe? that 
an IBM 433i/Nl with BMB of memory v^ould be rc^quired to r^u.pport 400 
concurrent users. Approj; i ma Lei y 14GB of disi;. storaue would be needed. 
BLIS has been acquired by Columbia. Broi/jn, Joluns Hoplans. Indiana, 
and UC San Diego. While software lias been installed at several sites, 
no customer has a production system running. All of the institutions 
that have selected BLIS, witl» the exception of UC San Dieqo, liave 
received grant support or special subsidies. Columbia, Brown, Johns 
Hopkins liave received Pew Foundation grants and T'^diu-na will run the 
package on an e^Misting machine that has e>tcess . - ^ ' -Ity. 

'NQTis^as developed over the last ten years at Northwesterr^ 
University. NC3TIS runs on IBM machines under DOS. VM. and MVS. NOTIS 
is written in assembler and handles its own data management. The 
systems uses CICS for teleprocessing and supports an online catalog, 
acquisitions, serials control, circulation, and record maintenance. We 
believe NOTIS would require an IBM 4361 /M5 with 8MB of memory to 
support 400 users. About 6GB of disk storage would be required. NOTIS 
runs at Northwestern University, Harvard. Universitv of Florida, 
Auburn, Clemson, and Washington University. Ihe system has recently 
been acquired by Vanderbilt, University of Pittsburgh, Brigham Young 
University, and Colorado State University. 
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BLIB and NO I IS a-f-fo^r a di ii^tinct choicvi? in t^ru\s of hecTn lol or.) v , 
fiinctions Bupporie:?d, and cobL. Tc«ble t i de^-n Li f 1. tir^ Cciui Lai cqgLq -for 
bath ^sv«tc-*in*3 by ailernative method of operaLion. There:* arh) l:hr-ee nav?5 
in wliicli an ILS could be? operc^Led: 

1. the Library owns and o(De?rates the? macihinri?, 

2. the Library awns thie? machine and con tract r» witfi an 
existing computer center on campus -for operation 
(facilities management), 

3. tine Library contracts wiLli an e>tistina computer center on 
campus for computer tiine (timesharing - if this option is 
en^ployed it is (uandatorv tfiat all termiruxl devices on 

^ campus be able to easi 1 y connc?f.:t to the host) 

Cost estimates are provided for the first two methods. The latter 
category is not included as costs would depend upon the computer 
center i nvol ved . 

Note that Table 1 differentiates between the cost of providing a 
system available only through terminals in libraries (lablled LIBRARY 
ACCESS ONLY) and the cost of provi di ng a sy stern aval 1 abl e v. h rough out 
campus as v^el 1 as through terminals in libraries (labelled NEZTWORK 
SERVICE) . 
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TABLE 1 



ILS CAPITAL COSTS 
BY ALTERNATIVE 



HETHORK 
SERVICE 



NOTIS 

LIBRARY 

ACCESS 

ONLY 



DIFFERENCE 



1. LIBRARY OPERATED 12,086,500.00 11,897,100.00 1189,400.00 
NO FINANCING 

2. LIBRARY OPERATED 12,752,000.00 12,502,000.00 1250,000.00 
SYSTEN FINANCED 

3. FACILITIES fiAHAGEHENT $1,815,400.00 $1,662,000.00 $153,100.00 
NO FINANCING 

4. FACILTIES HANAGEHENT $2,394,489.00 $2,192,157.00 $202,332.00 
SYSTEM FINANCED 



NETWORK 
SERVICE 



BLIS 

LIBRARY 

ACCESS 

ONLY 



DIFFERENCE 



$3,270,730.00 $3,063,630.00 $207,100.00 



$3,826,000.00 $3,552,000,000 $274,000.00 



$3,041, 9B0.O0 $2,070,030.00 $171,100.00 



$3,524,307.00 $3,29B,629.00 $$225,678.00 



The -figures -for capital costs include central site hardware, 
communications hardware, terminals, hardvjare installation, remodeling 
■for a computer room, conversion o-f existing machine-readable records, 
and operating cost^ during the time the system is beinu installed and 
tested. The capital cost estimates assume that: 



1. an additional 4 FTE will be required -far a total sta-f-f o-f 7 FTE 
divided as -follows: 

1 systems programmer 

1 applications program(ii«r 3S 
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1 database admi ni atfator 

2 operators 

2. terminal installation averages *S00 per devices 

3. it will require 12 months after installation of the hardware 
and software to test the system, convert ejjistinu 
machine-readable records, install the terminals, and link the 
system to UMnet 

Operating costs will run :$525,000 during the first year of 
operation and will climb to about .$:637,000 for the fifth year of 
operation-.^ Some savings could be achieved in operating costs if the 
hardware is managed by the Computer Center. Such an arrangement would 
reduce personnel costs by :$^100,000 the first year and more in suceedir^g 
years. Actual savings would, of course, depend upon rates charged for 
facilities management. 



^ This includes the -^60,000 in operating costs necessary to make 
the system available throughout the campus 
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FIGURE 3 



0-7 

CO 



C R PITRL, 

$368,000- 
$27B,000- 



COSTS 

ONETIME, 



ILS 



$92,000- 




BRIDCE 

^OEBT 9ERV 
laONE TIME 
^BRIDGING 



YRl-INST YRl-OP YR3-0P 
YR2-INST YR2-0P 
YERR5 



System Installation and Operation 



Initial planning calls for installation of the online catalog, 
circulation, and records maintenance modules first followed by 
serials control and acquisitions. Tlie Library will, at tl)e 
completion of the three year period for which bridgina funds are 
requested, fund the ILS operating costs tlirouqh Internal reallocation. 
Introduction of an ILS will, over time, alter the shape and content of 
the tasks within the Library. Preliminary analysis of such changes has 
identified ^266,000 that can be reallocattsd to : /er ILS operating 
costs over the first three years-. Replacement of the card catalog with 
an online catalog will eliminate the need to file cards and the 
migration to an ILS will enable the Library ho redesign procedures and 
workflow- During the first year of product ioii :ri05,000 will be 
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realj. acatod from support a-f Gt^ac ta opcr cation of the ILS- Durinq the 
secunci year of operation anutlier -=ri36,000 will be available due; to the? 
el i mi nation o-f card filing and maintenance. And in the third year 
^?S-000 v^i 1 1 become available Lhrouyh reallocation of INMDVACD 
operating costs. In addition, the Library v^il 1 please out 18 positions 
durinq the first 18 months tfie system is i^ble-: lo support opera\Lions. 

The Library is undertaking a review of policies and proceduren , 
especially in the areas where some duplication of effort betv^^en units 
has been necessary because of lack of access to a centralized database 
or v^^fiere the function of the automated system reduces or eliminates the 
need for staff intervention, in order to identify additional fur^Js 
that can be reallocated to ILS operating costsi. Tl^ose oreas wit- high 
potential are circulation, pre-orde^r searching, sifci'ials control, record 
maintenance, government documents processing, arid i-ecords creation. 
In order to determine the potential for additional fund reallocation, 
a cost study will be undertah:en this fall that will gather the data 
needed in order to restructure? and realign library services- 

Project Sciiedu j^e 

During the spring and summer *5f forts will ftjcus on a detailed 
review of N0TI3 and development of an implementation plan. Functional 
specifications are under review bv staff uroupv. cintl will be finalizetJ 
by the end of June. NOTIS will be revievrc^d c^.gainst the functional 
specifications and a decision reached by the end-ri^ July Additional 
tasks in the project are identificed in Table 3- 
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TABLE 3 
ESTIMATED PROJECT SCHEDULE 



TASKS 



SCHEDULE 



OTRI QTR2 QTR3 0TR4 0TR5 QTR6 QTR7 QTR8 



1. 



3. 

«. 

5. 

6. 

7. 
8. 



FIIIALIZE CEHTRAL = 
SITE HARDMARE 
CQNFieURATIOli 

FINALIZE 

COMHUHICATIONS 

NETHORK 

BUILD TABLE AND 
INSTALLATION FILES 

REKODEL COtlPUTER 

Roon 

INSTALL CENTRAL SITE 
HARDHARE 



INSTALL PORTION OF , ^ 
COHNUNICATIONS HARDWARE 



INSTALL SOFTWARE 

CONVERT EXISTING 
RECORDS 



9. TEST NOUS 

10. DEVELOP CUTOVER 
PLAN 

11. INSTALL REMAINING 
COHNUNICATIONS 
HAROMARE 

12. INSTALL TERttlNALS 



CCSTS 



$150,000.00 



$557,500.00 



$300,000.00 

$145,000.00 
$100,000.00 



$72,000.00 
$300,000.00 



Basrad on our preliminary c^nalysis we believer that NOTIS best meets 
the needs of the University. NOTIS supports all -functions, is 
substantially less esspensive than BLIS, and has a proven track record- 
Should the detailed review of rv:,;f'IS reveal shortcomings which would 
prevent us from acquirina the system two alternj^tive courses of action 
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could be lid^l'iuMi. First, the Library arid Univeraitv could elect to delay 
acquisition of a systGrn witl'i tlie eijpectation that cuiditional products 
better suited to our needs will emerge in tlie next 18 to 24 morrths. Or 
second, we could explore the possibility of a joint development e-f-fort 
with NorthV'iestern that viould remedy any deficiencies. 

Conclusion 

Based on the experience of other institutions, the evidence 
indicates that an Integrated Library System will create an 
environment whereby the Library will become an eveii more vital source 
of information and documents- The proposed system will come? to be an 
important tool available throunli the scl»ol€.M"s' workstation and will 
serve to integrate the? various computing and information resources 
available across the campus. In this vein . an Integrated Library 
System is in keeping with University's desire to provide state of the 
art computing and information retrieval resources. 
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NOTIS at Rice University 

Introduction 

This summary history of Rice University's acquisition of NOTIS as an 
Integrated library system ha3 been prepared for Inclusion In this SPEC Kit In 
lieu of the usual documentation, which In Rice's case was Intentionally not 
produced during the selection and acquisition process. 

Background 

Rice began a comprehensive retrospective conversion of Its card catalog 
In 1981. We decided to convert first and buy a system later, on the grounds 
that system hardware could be expected to become cheaper and more powerful 
over time. A disadvantage of this choice was that local MARC fields had to be 
formatted without our being aware of the particular requirements of the system 
eventually to be chosen. Also, the schedule for the recon project Imposed by 
the university did not allow for subject authority work. This effectively 
ruled out In advance any system without Boolean keyword searching. Conversion 
was done from the public catalog, In-house on new OCLC terminals, by temporary 
staff. OCLC records were found for 95% of the collection dnrLng the first 
three years of the project; in a second pass, 50% of the remaining titles were 
found in OCLC, and the remainder were input as new records. A side effect of 
the conversion was a massive Increase in interlibrary lending requests from 
other OCLC libraries. 

System Selection 

Local considerations ruled out any system design at Rice, or the purchase 
of a system which would require extensive modification or staffing. 

During the final year of the conversion project, members of the library 
staff surveyed the market for available systems. The approach taken was 
perhaps somewhat unusual, and was driven partly by constraints of time and 
funding, and partly by our observation that the traditional method of acquir- 
ing systems was often unsuccessful in other libraries, including some which we 
had the opportunity to observe rather closely. 

The acquisition was directed by the Associate University Librarian, work- 
ing with selected staff members chosen for their skills, interests, and dedi- 
cation to the long-term interests of the library. No committees were formed, 
nor were any consultants hired. Since we were not going out for bids, we did 
not write specifications or a request for proposals. 

Instead, we examined the available systems, quickly ruling most of them 
out for any one or more of a number of reasons. Among others, we eliminated 
any system which: 

—was totally turn-key, such as CLSI (which had provided our previous, 
circulation-only system), GEAC, DataPhase, etc., or: 

—was not Installed in any fully operational site where we could examine 
it, or: 

—was not supported by a company with a reasonably reliable financial 
future, or: 

~could otherwise be eliminated based on information we already pos- 
sessed. 34 
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The reason for the first of the above restrictions was that we had no 
desire to be locked into a single company for all of our hardware needs, 
including additions and expansions. We preferred to take advantage of ongoing 
competition in the marketplace. 

We thus quickly narrowed the possibilities down to a small number of 
offerings, which we set out to examine in detail. These were: 

BLIS, from Biblio techniques 
NOTIS, from Northwestern University 
PALS, from Sperry Corp. 
TOMUS, from Carlyle Systems 
VLTS, from Virginia Polytechnic 

Evaluation 

We compared and evaluated these systems through the usual demonstrations, 
site visits, etc. More usefully, we challenged each vendor to demonstrate an 
ability to load records from our own OCLC tapes. We also insisted on unlim- 
ited dial-up access to a large database running in an installed on-line cata- 
log subject to normal use. We then asked a number of library staff members, 
students, and faculty to examine and react to the different systems at length. 

One of the vendors was unable or unwilling to provide such access. Their 
explanation was that remote access to their system was so difficult that it 
could not be undertaken without our having one of their staff members pre- 
sent. Another system, although it had numerous installed sites, could not 
provide access to one which had both a large database and acceptable response 
time. 

Thus there were three final contenders. Two of those were NOTIS and 
PALS, which we examined over a period of several months from dial-up terminals 
and through visits to operational sites. The third was TOMUS, which Carlyle 
Installed in our library, with seven terminals and a database of 163,000 of 
our OCLC records. 

Our experience with TOMUS as a representative public catalog was encour- 
aging. Within minutes of the system coming up, card catalog use dropped 
virtually to zero for the entire five months of the test, including times when 
the system was down. The keyword searching facility of TOMUS did, as we had 
hoped, more than compensate for the lack of subject authority control. 
Indeed, we observed that most subject retrieval utilized fields other than 
subject headings. We had asked Carlyle to construct a keyword-in-entire- 
record index, and soon into the test most users were using that index exclu- 
sively, rather than specifying particular fields to be searched. 

Our experience with each of the three finalists was highly positive. We 
eventually chose NOTIS for a variety of reasons, many of them unique to Rice, 
and we have no reason at this point to believe that any one of the three 
would not have been successful. 
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Purchase 

NOTIS software liari a set price, varying only according to the operating 
system used, and runs on IBM-conipatlble hardware. Our funding permitted the 
purchase of a new IBM computer to be dedicated to NOTIS, so we chose that 
route rather than any of the several less expensive but also less desirable 
options. We acquired Telex terminals for the most part, since at the time IBM 
had still not come to Its senses and produced a library terminal. 

Our software contract was an expansion and revision of one previously 
negotiated between Northwestern and another university. The aegotlatlon 
process was short and mutually satisfactory. In part because NOTIS Is a well- 
established system with most of Its anticipated pieces already In place. 

Installation 

We signed a contract with NOTIS In June, 1985, and sent out purchase 
orders for hardware In July. The hardware, operating system software, and 
NOTIS software were Installed early In October. We began test loading of the 
database later that month, while simultaneously Installing wiring and cabling, 
making connectors (etc.), undergoing training In the technical services 
modules, and building parameter tables for all the modules. We discovered 
that a number of Idiosyncrasies In our local holdings formats required pro- 
granunlng changes by NOTIS staff. By the end of March, i^.viirythlng was ready 
for system Implementation* The actual database load of 600,000 records took 
18 hours. Public terminals were not Installed until the beginning of May, to 
avoid the confusion which would have resulted from the appearance of a new 
form of catalog i:-',, the end of the academic year. Circulation came up In mid- 
May, after CLSI ' )m records were downloaded to NOTIS through a CLSI terminal 
port. 

Conclusion 

We chose not to follow the standard approach to system selection for a 
number of reasons, the main one being our belief that that approach Is slow 
and Ineffective, and serves primarily as a vain attempt to protect the selec- 
tors In case a disaster ensues. We felt that the best way to protect our- 
selves from a disaster would be to avoid one, so we relied heavily on a small 
number of staff members of exceptional ability, three of whom deserve special 
commendation: Kay A. Flowers, Circulation/Systems Librarian, who serves In 
place of the 3 F.T.E. prograramer/aTi.ily.st:? we can*t afford; Anne G. Adler, 
Director of Processing Services; and Shirley Wetzel, Retrospective Conversion 
Supervisor. 



James C. Thompson 

Associate University Librarian 

May 16, 1986 
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, , , , , psy Communication 

Subject Ad Hoc Cotnmittee on implementation of an a iJComate;d 
acquisition system. 



Dale '^Pril ^» 19B^ 
From 



To 



By this memo, I am asking you to serve as chair and those listed belou to 
serve with you on an Implementation Committee for an Automated Acquisition 
System. 

The other members of the committee are as follows: 



The Ad Hoc Committee on Space Allocation, whose charge is attached will 
report to Divisions Heads, however, it would undoubtedly be useful for 
Mike Grimes, as chair of that committee, to serve as an ex officio member 
of the Committee on Implementation. Administratively your committee should 
plan on reporting to the Ad Hoc General Review Committee for implementation 
of an automated system and ultimately to Division Heads, While I certainly 
do not expect you to keep detailed minutes, I do ask that the Committee, in 
the person of Dr. Straley, maintain a record of discussion topics, decisions 
reached and recommendations to be made to the General Review Committee. 

There are some assumptions upon which the Committee should base its work: 

1. The system is to be delivered by June 2D, 198^. We should 
plan to be up on the system at the beginning of fiscal year 
1985, at which time our agreement with LI8RIS will be cancelled. 

2. Monographic Acquisition Division will be in charge of the physical 
maintenance of the system, including tape loading and unloading, 
backing up the system serving as the coordinating point for all 
maintenance and service issues. 

3. The Ad Hoc Space Allocation Committee will undoubtedly be making 
recommendations, based on their charge, that will influence your 
decisions and vice versa. I assume that there will be close 
communication between the committees. 

The specific issues that I expect your committee to address are the following: 

1. Initial transfer of present functions to the on-line acquisition 

system. In order to move into full use of the syshRin, current 

functions need to be transferred quickly. There will undaubtp«ily 

be many additional changes and adaptations as we learn more about 

the System and its relation to our present and DSU's required pro- 
cedures. 07 
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^' transJBr^'"fn\h'' -"^^ ^^d continuation order 

transfers to the neiu system. 

a. Among other questions, houj do ujb encumber free 
serial monies by fund ujhen there is, at present, 
no initial allocation or encumbrance? 
J^en or do UJB conv/ert outstanding unit orders and 
carry forward funds? 

c. Houj long must uje run dual accounting systems? 

a. «t ujhat point do uje replace SAPP with Innouac! 
can UJB run a tape of the bibliographic SAPP 
information to Bstablish the primary data base 
on the automated serial financial system. 

evaluate and .ake reco-endatlons on any topics you ?lel apJroprLje. 
If you hauB any questions or if I can be of any help, please let me knouj. 



GDH:cv/ 
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OHIO STATE UNIVERSITY _____ 

bsu Communication 

Subject Ad Hoc Committee on Space Allocations, ^^^^^^ ■ 

Task Force on Innouatiue Interface (INNQWALj 



Date Inarch 26, 198a 

By this memo I am asking you to serv/e as chair and those listed below to 
serue with you on a committee to allocate space to prouide for installation 
of the INNOl/AC system. 

The nt:hRr mRmhors hnrRhv askpH hn spr\/R on the committee are: 



:)pec;iricatlons tor space and electrical needs are attached. In making 
recommendations For the arrangement of our limited space the following 
assumptions should be made: 

1. The Monographic Acquisitions Diuision will be responsible 
for the physical on site maintenance of INI\IO\/AC, 

2. The CPU (central processing unit) and the tape deck will 
reside in □36. 

3. There will be eight teiuiinals and two printers, 5 terminals 
and one printer in O^ON and 3 terminals and one printer in 036. 

4. There will be a satellite installation at Health Sciences 
Library consisting of one terminal and one printer. They should 
be asked to prov/ide site information to us. 

5. All of the INNOl/AC in Main Library, as well as that in Health 
Sciences, must be run off a dedicated electrical circuit. 
Gerry Guthrie will hav/e to be approached on this issue, once 
locations are set. 

6. Communication connections with Uniuersity Systems must be 
established. Karlene and Susan will be especially helpful 
in this matter. 

Based on the abov/e assumptions, I am asking your committee to recommend 
reallocation of space to accommodate the new system. After the uery 
successful mo\jB last spring I don't think we need to do a niassiue change, 
but rather to shift things slightly. Please consider heretical options, 
particularly in O^ON, including, but not limited to: 

1. Compacting of CSR and remov/al of resulting empty cabinets. 

2. Shifting of current check^in files. 

3. Remov/al or rearrangement of mail sorting area. 

I would also like your recommendaitons for equipment ner:i?r,sary to house 
INNOUAC, including work stations, chairs, etc. 

As you know, the system is out on bid. Until the bids are rpceiv/ed and the 
final one let by the Univ/erslty, we cannot mov/e on actual wiring, but the 
inuestigations, planning and preliminary establishment of work dates should 

be accomplished as soon as possible. I am most grateful to you for your 
help, and the applications of vour skill; in this project. 
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OSU Communicatiol? 

Subject Subcormnittee on LCS Headings Control 
Date March 17, 1963 
From 
To 



In order to facilitate the continued planning and Inipleinentatlon of 
LCS headings control, I am asking you to accept a one-year appointment 
as chairperson of the Subcommittee on Headings Control beginning 
Immediately and not to exceed one year. By a copy of this memo, I 
am asking the following to serve with you: 



The specific tasks to be accomp.t ' by this Subcommittee Include: 

1. Complete programming speclticatlons for the processing of Library 
of Congress Name Authority update tapes. 

2. Complete programming specifications for the processing of Library 
of Congress Subject master tape. 

3. Develop specifications for reports to come from the processing 
of the Library of Congress authority tapes for LCS. 

4. Develop a plan for the retrospective conversion of the OSUL 
card authority files. 

5. Define improvements for headings display on LCS. 

6. Recommend changes in cataloging policy which will facilitate 
user access and use of the LCS headings file. 

7. Identify problems in headings and propose solutions to these problems. 

8. Monitor the development of authority control nationally aiH keep 
the OSU Libraries aware of pending changes which will affect LCS. 

The reporting line for this Subcommittee is to the Committee for an Online 
Catalog. 

WJS:vm 
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OHIO STATE UNIVERSITY 

Task Grotip on Describing current OSU Communicab'on 

Jubjecl LCS reports for collection management. ^^^^^^^^'^^'^^^mam^m^tmm^^^mmmm^ 

Date November 23, 1982 
From 
To 



I ask that you chair a Task Group to describe the current 

output reports from LCS for collection management — along lines 

of the discussion in the meeting of November 22 — and by this 

memo I am asking the following to serve with you: 



What I think we need is a clear description of wliat records 
are produced by LCS on what frequency basis; why the records are 
produced; and how they are best used* The purpose of the description 
is to provide documentation (and thereby under standing) f or all who 
receive these records and to promote the most effective use of tliem, 

I do not view this as a long-term effort; and in fact hope 
that you would be able to complete s\jch descriptive dociiinpnt at ion 
in a couple of sessions. 

Let me know if you have questions. I'll be happy to meet with 
the Task Group at the outset if that is deemed desirable. 

WJS: vm 



ERLC 
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OHIO STATE UNIVERSITY 

OSU Co mmunication 

Palo 4uly W,:i»79 

From. 
TP. 



In ordar to faollltat* tha continued planning and Imnlemcntatlon 
for LOS authority control, I am aaklng you to chair a SgbconuBlttea of\ 
ICQ Authority Control j and I an harawlth rpnueatlng the following to 
80rv0 with youi 



. Blnce much work Is atm naceasarv In the daalgn and implementation 
of tha LCS authority control, and ainca ria, Millar would normally 
aonaull: with thasi ^ndivldualn aa inJormoClon aourcea, It la approprlata 
tf hava tham offiolallv appointed and thereby acknowledge thelv function 
in' tha: diVfflQRmont; of: the LCS authority control, 

- Tha apBciflo taikii'whichi' Z woulU Atil'^hi'td' thl.i 'iubeobiiltttoa kr«i 

4.' Davfflopmant Qf tho online rnAlpcenanct speclficaclona ' 
vnicn thi LCB' programme r« hava designated ae Phae^i 3 
pt their docupienc Propoaal for Closing cha Card 
CatrilDg pf OSU Ubrarlas,!. 

.2 Prepartng.il facopmendat ion for the purchase, u^e, and 
archlvinn off.the Library. P( Congresa au 'lortty tapes, 

it Berving-arf pirpgrlaWnbi:<)'eo^sultdn|:'* b'tf^ ff^e brPgrAihmlagi of 
I4C0 authority* control proceeds. 

* i^r Honitor the] development if ilARO' authority" fo^njJits,'! 
. specifically* perlea authority ^nd "the 'Library of 
Congress implementation of the autf^ority forpats, 
Pflr|;ipular4.y series- and aubjecta. I 

^1 Monitor P.ia development of the OCLC authority control 
capability and recommend the procedure for I'lnfegratlng'? 
ithe;,pCW capabilities with ICS authority control. 

The fcrm of appointment for the subcommittee Bho^ld bo through 
the Implementation of complete LC9. authority . control •^ tentatively 
throe ye^rsrand the reporting line is tof the«Commifctce' fof^an online 
Cuicajpg, 

WJBivm 
cai 
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Subconnnlttco on LCS Uoldlugs Ilocords 
Jund 21p 1979 



I am aoklog that you chair a Subconnntttca on LCS lloldlriRn 
Bocorda (a aubconnnlrtaa of tho Commlttae for an Onllna Cntalog), 
and by thla aaoo tDonio I am aaklng tha foUovlng to sarve vtth you! 



CharRO 

* Recommend corroctlonB, changes nud Improvcn^inta in LCS vMilch 
win euUauce the format, malntonanco, and uao of the ecrlnl/ 
moaoset holdings racorda, 

* Report to the Comvit: ea for an Onlirtt Catalog. 
Mombershlp ' 

The Subcotnoittea shall be compoaod of seven rep.ulnr ntonhcrn 
appointed by the Director of Llhrarloa. An Qlj?Jitfi momber, tlio 
Coordinator of Automatdd rLlbrary Syntoms, shall -aorvo na Chnl rnorfion. 
The aaven regular nwmbera will be appointed for two-year atnggered 
terms. 

I am very grateful for the oxpreanod willinjjncpn nnd liiirerest 
to aarve in this capacity, Tho apociflc iague In question I3 n 
critical one with reforonca to how ooaily and woll stsff nn'l pntrons 
can accurately Interpret aorial/monoaet holdings recorded on LCr:. 

WJSivm 
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u^u truniiiiuiiJUciuuii 

Subject Committee on Education for Online Library Systems' ...^^ 
Date June 21, 1979 
From 
To 



I am asking that you chair a new conuoittee to deal vith the 
broad area of staff and user education/instruction for online systems; 
and by this same memo I am asking the following to serve with you: 

Appointment Thro ugh 



The charge/committee description is attached; and it should 
be understood that this assignment falls within assigned time 
according' to the recently approved policy on that issue. I am 
most grateful for the expressed willingness and interest to take on 
responsibility for the critical area of the ease ond effectiveness 
with which LCS can be used by staff and patrons. The best technical 
design possible is rendered fallow if system patrons cannot easily 
and effectively use the system to desired ends. 

WJS:vm 
cc: 



thf Ohip otllt univf nily 

Form 70^Rtv ft 76 Siort | ^tO 
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Committee on Education for Online Library Syste 
Charge 

* Initiate and coordinate the development and continuation of 
programs and material:: which will instruct Hbr.iry p.ntrons 
and library staff In the usu of l.CS. This Is not Intended 

to preempt .t.. .f Instruction programs developed by Individual 
units which relate to LCS and/or OCLC use In specific areas. 

* Jp^'^J^*^^ ^"'^ coordinate public relations efforts relating to 
LCS for the OSU community, and for other Individuals, groups 
or organizations. 

* Recommend corrections, changes and improvements In LCS which 
will enhance and facilitate patron and library staff use of 
the system. 

* Serve In an advisory capacity In responding to questions con- 
cerning the use of LCS and OCLC by OSU patrons and library 
staff. 

* Coordinate the Committee's activities with the Committee for 

an Online Catalog, the Committee for Library-Patron Conununication, 
the Committee for Continuing Education, and the Director of User 
Education. 

* Report regularly to the Director of Libraries and the Libraries' 
Automation Committee. 

Membership 

h« .^^/°"^"ee shall be made up of five regular members, appointed 
Jutot%^J'MK'" of Libraries. A sixth member, the Coordinator Lr 
Automated Library Systems, shall serve as Co-chairperson on a permanent 



of thV^ t members shall serve for two-year staggered terms, and one 
of these members shall be appointed by the Director of Libraries to 
serve as Chairperson on a one-year basis. oraries to 
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OHIO STATE UHIVERSITY 

i ci Committee for an Online Cata aa PSUOommunicalion 

Date June 21, 1979 
From 
To 



With t\:\i^1a'^^s^" 

requesting that'the fonowing s^r^^ wUh Jouf ' ''''^^'"^ 



according to our recentirap^oved^iSff/'^'^ r''"^ '''^^'^ '^^^ 
Committee's work is vital ?o our«uoopf ^^^^^^^^ «=o say the 

catalog control, and I ver^ mu^J f n f ^" entering a new era of 
of this group ik serving tLs pIlrpo's:!''''' ''''''''''' 



WJS;vm 
cc: 
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Committee for an Online Catalog 



Charge 



Advi8e and recommend relative to development of and transition 
to an online catalog. This includes consideration of issues 
related to "freezing" the public card catalogs, but does not 
involve per se the change from AACR I cataloging code to AACR II. 

* Analyze the pot;ential interrelationship between OCLC and LCS 
in order to nake recoumiendations concerning the integration 
between OCLC sybsystems and LCS. 

* Recommend corrections, changes, and improvements in LCS which 
will enhance its use as an online catalog. 

* Serve in an advisory capacity to the Coordinator for Automated 
Library Systems who responds to LCS programming questions 
which relate to input, storage, and display of bibliographic 
records on LCS. 

* Coordinate activities wf'-lr the Sub-Cbmmlttee on LCS Holdings 
Records, the Commitfceo • 'ucation ^or Online Library Systems, 
and other library uiii; <?r t committees as appropriate. 

* Report to the Director of Libraries and the Libraries' Automation 
Committee. 

Membership 

The Committee shall be composed of six regular members appointed 
by tne Director of Libraries. A seventh member, Carol Krumm, will 
serve as a staff resource person on the Committee. An eightti member, 
the Coordinator of Automated Library Systems, shall serve as Chairperson. 
The six regular members will be appointed for two-year staggered terms. 
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OHIO STATE UNIVERSITY 

. . OSU Communicalion 

bUDject lask Force on the Change-Over to On-Line 
Serial Records 
Date May 4, 1977 

From 

To 



I am asking that you chair a task force to be concerned with the many and 
various Issues relating to (1) the general use of on-line serial records within 
the LCS system, (2) the decision whether to opt for OCLC-based on-line serials 
check-In, and (3) the Inter-relatlonshlp (If any) between the LCS serial records 
and the potential OCLC file. I am, by this same memo, asking the following staff 
members to serve with you: 



The charge to this Task Force Includes, but need not be limited to, the 
following elements: 

* Determine, as soon as possible, the cost/b eneflt of using OCLC chtck— in 
for OSU serials; the cost/benefit of alternative check-in systems; an estimate 
of the cost to convert the OSU serial check-in records to OCLC; the sources of 
cost recovery if OCLC check-in is recommended; and the effect of decentralized 
OCLC check-in in the OSU Libraries ~ culminating in a recommendation regarding 
the use of OCLC check-in at the OSU LibiTarles. 

* Develop a plan for converting selected physical volume holdings to machine- 
readable form for LCS. Considerations are: (1) rationale for Inclusion (a. user/ 
patron; b. technical services aspects) (2) detailed work procedures (3) conversion 
work assignments and (4) costs, time tables, and priorities. 

* Develop a plan for improving the serial holdings d\Qplay on LCS including 
examination of the use of physical versus summary holdings statements and the 
clarification of incomplete or othen^ise confusing holdings statements. Also 
investigate whether the LCS serial record can be expanded to Include notes re- 
garding title changes, etc. 

* Plan for the maintenance of the LCS Serial Holdings File; Including investi- 
gation of OCLC/LCS interface feasibility, the relationship of the Central Serial 
Record and/or the OCLC based serial record to LCS, and methodology of LCS main- 
tenance if manual check-in is continued. 
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May 4, 1977 



Coordinate activities and exchange Information with the concurrently 
operating Task Forces on the Change-Over to an OnTLlne Catalog and on Education 
for Patron/Staff Use of On-Llne Systems. 

* Act In a liaison capacity In answering questions raised by progranuners as 
they proceed with development of the LC^- Serial Holdings File. 

Assignments can be accomplished by the Task Force as a whole, through 
sub-committees drawn from Task Force members (appointed by the Chairperson), or 
through ad hoc sub-committees to be appointed by the Director upon advice of the 
Task Force Chairperson. 

Since this Task Force effort is so vital and will doubtless require con- 
siderable time, I am designating your and the Task Force members' participation 
as an assigned-tlme activity. 

Please accept my advance thanks for your willingness to take on this moat 
important of endeavors as we move toward an on-line mode which can be acceptable 
to and effective for both the library and its users. I look forward to the Task 
Force report. I would also be pleased to meet with the Task Force early on in 
its deliberations in order to ampllfy/elucldate/clarlfy the charge, and Indeed 
at any time throughout the course of proceedings. 

WJS:vm 
cc: 



Ohio State UnlverBlly Librorlo* 

RECEIVED 

PEHisoi^neL office 

MAY 5 1977 

AM PW 
7i8|9|10|ll|12|li2|3i4|5|6 
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RI£l'=-Ch:r OF THE AD HOC COMMI fTEE ON FUTURE INFORMATION SERVICES 
Introduct i on 

The charge to the Ad Hoc Committee on Future Inf ormat ion 
Services was to eiKplore future directions for informational 
services at Texas A?<M University Library and to develop a plan to 
guide the Library in terms of automated access to information 
into the next decade. 

In exploring future directions for automated information 
services, the Committee members researched and wrote papers on 
the following topics: 

1 ) the user 

2) i n format ion 

3) access to information 

a) means and technology 

b) the role of libraries^ n the future 

c) the role of librarians in the future 

d) macro and micro organisational considerations for 
libraries in the future 

e) fiscal considerations. 

These essays are attached to the report as appendices. 

The body of the report consists of a series of 
recommendations or»3ani::ed under each of the broad topics outlined 
above. As a whol';,. t^ie^'*:- should be considered as a plan to guide 
the University Uxi>f^*Ui"-y through the upcoming decade. 




TEXAS A & M UNIVERSITY 



P ^l i 1 ci s »".' hr i c 1 Out 1 ook 

Under 1 yi nq the recommeridat ions are soever al principles uhich 
guided the Comrriit tee iri its deliberations. Premier amoni;.! these 
principles is the concept of utilizing informational technologies 
to enhance levels of service to users. The Library will 
aggressively seek to integrate electronic information transfer 
capabilities as they become available, feasible and cost- 
effective, Tujo major goals became clear in the course of the 
Committee's discussioni-: (1) to supply information in all forms 
to users on a no-charge basis, and (2) to establish the. 
University Library as the primary information center on campus. 
A prevailing thread through the Commi tte*^'' s deliberations was the 
recognition of the extraordinary demands that uill be placed upon 
library managers in the next decade. Library administrators must 
carefully choose a path which will take advantage of developing 
technology without losing the benefits of traditional information 
control. Difficult decisions must be made. A delicate balance 
must be struck, for instance, in allocating funds for purchasing 
printed materials and providing online access to users. Finally, 
discussions of the library user dominated every topic 
investigated by the Committee. 



Within the ne>ct twenty years, the definition of the Texas A?/.M 
University user group will change significantly. Technology will 



Users 
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ext e n »J the s p h o r e •:• 



f th\^ Library's influence beyond present 



geographical boun»:Jar ier* . Future users uill be more computer 



literate than users of today and uill be more demanding of the 
benef it s avai 1 ab 1 e to t hem from computer i zed services. User 
training in neu information technologies uill be a critical issue 
facing librarians in the upcoming decade. Librarians must be 
prepared to train several levels of users uho uill have varying 
levels of sophistication in automation- 
It can be expected that some users uill continue to need the 
most basic of instructions in library use, uhile others uill seek 
proficiency in online searching at varying levels of difficulty. 
Thus the teaching function of the academic librarian ui 1 1 not 
diminish in the future? the need to acquaint the uninitiated luith 
informational resources and their access uill remain a 
significant function of the librarian into the foreseeable 
future. 

A 1 though the use of improved techno! ogies uill foster the 
groujth of the University Library's user group, levels of 
responsibility to the varying segments in the expanded user group 
tuill not be equal. Roughly speaking, users in rank order of 
priority might be considered as follouss 

1) students (former and present), faculty and staff of the 
TAMU Co 1 1 ege Stat ion campus - 

2) TAMU system personnel and students? 
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3) HARLiC users; 

4) local area residents; 

5) Texas state residents; 

6) U.S. residents; 

7) international usersn 
R;i«corrirriendat ions 

The User 

1) An emphasis should be placed upon user training during 
the transition from a print to an online mode of information 

t ransf er . 

2) The University Library should strive to offer remote 
access capabilities to local bibliographic databases and to other 
automated databases . 

Access to Information 
Means and Tec hnol oqy 

1) As is practical and feasible, the University Library mill 
substitute electronic access for information sources previously 
published in printed form. Little used and/or expensive titles 
will receive first consideration for such substitution. 
Cooperative purchases of electronically stored information uill 
be considered. 

2) Full document delivery to campus users should be 
instituted as soon as remote access to local bibliographic files 
becomes commonplace. The viability of a full document delivery 
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program should be phased in by otrvsring services to West campus 
users in the near futur^:?. 

3) The Library should aggressively pursue options for 
providing electronic access to uncataloged collections. 

a) The use of commercial databases i^or providing p«artial 
access to some uncatal oged co 1 1 ect ions, e- n. , NT IS and U, S- 
documents tnat«5rials, should be expanded, 

b> If an uncataloged collection is viewed as a suitable 
candidate for cataloging through a cooperative project, the 
Library should not catalog it locally. The Library will se^k to 
engage in cooperative cataloging projects to fulfill a 
professional responsibility and to gain access to cooperatively 
produced mac hi ne-readab 1 e bibl iographic data. 

c) The Library should provide local access to all 
uncataloged materials considered unique or otherwise unsuitable 
for bibliographic control through mul t i— 1 ibrary cooperative 
projects- Local access assumes a wide range of bibliographic 
control- Some categories of uncontrolled materials should be 
assigned an indexing type of access, while others should be 
assigned -part ial or full cataloging types of access- 

4) The Library will provide remote access to materials 
housed in the Library and to other material available through 
1 i brary ser vi c es . 
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5) Tho Library uii 11 provide? the means for users to serves 
themselves when technology permits through the performance of 
their ou/n searches. 

6> The Library should assume responsibility as principal 
catalyst for obtaining funds and resources, and for providing 
services in satisfying informational needs of users. 

Access t o I nf ormat i on 

Organisat ional Con s i derat i on s 
Macro Consider at i o n s 

1) Printed and electronic versions of the same 
information should be b ib 1 i ographi cal 1 y controlled together. The 
f-*rr,. . or form of information will not be the overriding 

ori.^r^.. rational determinant; the substance of the information will 
prevai 1 . 

2) Job descriptions for library staff should be 
rewritten to include some combination of computer literacy, an 
emphasis upon subject specialisation jhen appropriate and other 
non— t rad i t i onal skills- 

3) The Library should evolve in tandem with the 
application of information technologies and user needs. 
Flexibility and innovation in organisation uill be of extreme 
importance now and into the future. Specific needs and their 
significance to the Library organisation can be expected to 
change quickly and radically. Staff should be allocated in light 
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of rivi-ed; a continual r eassei.'Sment of staff needs is rec orTini^=f nde d 
as the envi r onfTu=f nt changes. Staff should be moved as dictated by 
demand . Organ i sat i onal mode Is other than t he t rad i t i onal 
pyramidal structure, e.g., a matrix pattern, should be considered 
in light of future needs. 

M i c r »:» Cons i derat ions 

1) A fund raising unit should be established in the 
Library to generate the large amounts of funding necessary to 
purchase equipment for automated services and oth^r neods. 

2) An automation staff person should be added to deal 
with public information systems. 

3) The Library should strive to participate as a leader 
in netujorking and similar cooperative systems, e.g., 
bibliographic utilities, and regional and national automated 
informational services. 

4) The Library should strive to become a center for 
storing and servicing data files. Other campus facilities 
involved in working with such files should be coordinated through 
the Library in order to maximize use of funds and staffing and to 
ensure the concept of centralized information control. 

5) The Library should strive to take advantage of neuj 
technologies and to participate in neu modes of information 
distribution as available. 
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The Rol Cf of Li braries 

1) The Texas A2<M University Library should promc.te 
flexibility in moving from a print-on-paper orientation to an 
online access mode of thinking. Libraries as warehouses of 
printed inf orrriat ion will decline rapidly in relevance in the next 
decade. 

2) The concept of the library without walls should be tested 
immediatCfly by offering rerriote access to Data Phase and full 
document delivej^y services to West Carripus users. 

3) Planning should begin immediately for the construction of 
a new building to satisfy space needs of the Library, While new 
technology will provide more efficient means for storing data, it 
cannot be relied upon to solve all of the Library's space 
problems. The concept of off-site technical process ing shou 1 d be 
expl ored. 

4) The Evans Building should be immediately reassessed and 
reviet;ed for space utilisation in light of neuj technologies and 
cha.iging staff and user needs. 

5) Patterns of collection devel opment shoul d be -redirected 
to include the following principles and/or concepts: 

a ) Co 1 1 ect ion deve 1 opment ef f ort s shal 1 emphas ise t he 
acquisition of space-saving formats such as micro and electronic 
formats with maximum retrieval capabilities. 

b) On a case by case basis, the Library should eliminate 
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expendable materials, o. g. , print duplicates of journal? and 
i n dexe s ava i 1 ab 1 e o n 1 i ne . 



the ijpperfTiost goal of satisfying user informational requirements 
i.e., access to information will be the critical issue in the 
future and not the storage of information in printed form. 

d) The Library should become a center of an automated 
information network on campus. 

The Rol e o f Librar ians 
Recommendat ions 

1) Funds and time should be allocated to retraining 
professional staff in automated information applications as they 
become aval 1 abl e. 

;2) In view of technological advancements and the 
University's emphasis upon graduate education, there will be an 
increased heed for subject s'pecial ization in the professional 
staff. As a r/^' lit, an increased emphasis should be placed upon 
recruiting star/ with advanced degrees in addition to an MLS. 

3) The Library should bring pressure to bear in th^-' 
profession at large to train library science students .• 

i nnovat i ve i n f o rmat ion technologies. 

4) The Library should place a high priority upon becoming 
nationally competitive in salaries in order to attract the most 



c > Material s budget al 1 ocat ions shoul d be e>:: 



p e n id e d with 
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qualified people, 

5) Staffing needs should be continuously reassessed in light 
of service needs. 

Fiscal Cons 1 de rat ions 
Re c o mme n d a t i o n s 
I n t r o d u c t i C' n 

To provide automated services to f-:r..*s on a regular basis, it 
will be necessary to reconsider traditional library budgeting 
philosophies. Materials budget lines might be renamed 
"Acquisitions and Access" lines to conform with a shift in 
emphasis from owning to accessing informational sources. It can 
be expected that there will be a gradual shift in the ratio of 
acquisitions and access budget lines from acquired printed 
souTces to access services over the next ten years. 

The consideration ov chargi'rd vs. no-charge services ifjill be 
of great importance. Eventually, the Library should supply 
information to users on a no— charge basis no matter how the 
information is accessed or acquired. It will be of some 
significance, therefore, to allocate regular sources in the 
Libr^a.ry^s budget for access services. A gradual, phased-in 
approach to incorporation of access services into the mainstream 
of library services will be ba^^d fir^t upon the consideration of 
feasibility and practicality both in terms of funding and 
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staffing. Iij fore-casting phased-in approach the folloujina 
recoiTimeridat ions could be made: 

1) The graduate student AIRS prograiTi begi-n in the fall of 
1983 should be continued and expc ed. 

2) There should be an increased acquisition of backruns of 
periodicals in mi crof ormat ; de-se 1 et/c xon of hard copy equivalents 
should progress in tandem with acquisitions in microformat if use 
patt erns al 1 ow. 

3) On a t it 1 e-by-t it 1 e/case-by-ca5;<^ basis subst i t ut e ac ce ss 
to online indexes for print subscriptions- 

4) The Library should provide dial-up access or unlimited 
in-house use of databases for which the Library would pay a fixed 
fe?^ for unl imited access. 

5) The Library should provide current awareness services. 

6) Non-bibliographic databases should be made available to 
users on an unlimited access basis if cost-effective and 

f easibl e. 

7) Full-text databases should be made available to users on 
an unlimited access basis if c ost— effect ive and feasible- 

S) Acquiring dat ^h^>ai.Cf s and allowing users unlimited access 
in the local environment should be considered. 

'?) In view of the change in errij^h-asis from owning to 
accessing, the Library should recommend that ARL consider access 
budgets, e.g., funds spent on automated information retrieval 
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sa-rvicoD and the number of o-^^rabases accessed, as significant 
statistics in determining library quality which should be 
compiled, analyzed and disseminated as part -of the ARL 
Statistics : particularly as a variable in the ARL Library Irndex. 

10) The Library should allocate additional staff positions to 
eet the increased demand for automated services. 

11) The Library should allocate funds for professional staff 
development for retrai n i m^i , updating skills, and providing 
opportunities for staying abreast of developing technologies. 

12) The question of access to electronically transmitted 
information gives rise to the problem of supplying copies 
(printed, tape, diskette, etc.) of information accessed online to 
users. The Library should gradually move to providing copies of 
such information on a no-charge basis. Again it can be expected 
that such duplicating services wil"; be phased-in as practical and 
feasible. 

Subject to copyright restrictions, duplicating servic-;:'S would 
be provided for the followings 
1 ) Automated Services 

a> Holdings from the online public catalog 
b > Circulation information 

c ) OCLC inf ormat ion from publ ic access terminal s 

d) Online printing charges for bibliographic data, fu1l- 
text and non— bibl iographic data 
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e> Offline print irnj charges for bibliographic data, 
full-text data and non-bibliographic data 

f) Information retrieved from databases 

2) ILL services 

3) Microtext matorials 

4) Audiovisual materials 

5) Software 

6) X^sroxing of printed materials 
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APPENDIX 



Formal Evaluation o f: Vendor Proposals 



To evaluate the complex proposals of library automation 
vendors, the Heard Library staff divided the systems into 
nine functions, A different team of the staff evaluated 
each function for all vendors. The teams were asked to 
summarize their assessment of a proposal in a given 
function using a score from one to ten . A s teer ing 
committee reviewed the reports of the teams and assigned 
weights to the functions- A weighted average of the scores 
*for each vendor then indicated the overall rating of the 
proposal. Of course, the formal evaluation- provides only a 
partial basis for a decision. A final decision requires 
additional judgement, taking account of factors like cost 
not included in the formal evaluation. The formal process 
is summarized here. 



The general assignment of each team follows: 

Acquisitions: How well does the system provide for 
tracking materials ordered and the associated 
accounting for funds? 

- Cataloging: How well does a system provide for the 
cataloging of materials? 

Authority Control: How well does a system allow the 
library to control headings used in the catalog? 

- Search: How does the catalog look from the point of 
view of the user? What search strategies are allowed, 
what help provided? 

Serials : How we 11 does the system provide for the 
tracking of serials subscriptions with the special 
holdings information and claiming required? 

- Circulation: How well does the system provide for the 
circulation of materials including reserve room 
col lections? 
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Management Information: How much information does the 
sysiiem provide to library managers that may be useful 
in e.valuating and plannincj library opera ti ons ? 

Additional Capabilities: What growth path does the 
sys tern prov ide f o r new ser v ices , ga teways to remo te 
da tabases and the 1 ike? 

Support: How well does the vendor support the system 
and how much responsibility will the vendor assume for 
the total performance of the system? 

Each team '^^as rasked to assign a score from one to ten to 
each vendor's proposal in the function assigned to the 
team . A scc*.e of ten means the sys tern del i vers everything 
we could want; a score of one means the vend or is vacant in 
thio category, A score of five means the system is 
marginally workable. From two to four indicates 
expectation in development. From six to nine indicates 
performance level. Ties and decimal ratings were allowed. 
Each committee justified its rating with a few sentences 
indicating the important differences in vendors in the 
given function. The attached table reports the ratings as 
adjusted by the steering committee. 

To summarize the overall rating, we could take an average 
rating across the nine functions as reported at the bottom 
of the raw rating columns. However, we may not view all 
nine functions as equally important. For the Heard 
Library, an automated circulation system and an effective 
public access catalog are of highest priority. We have an 
automated acquisition system and so acquisitions is of less 
urgency. Management information systems and added 
capabilities will be valuable but are not as important as 
the more fundamental features of the system. By assigning 
differential weights to the functions as shown in the first 
column of the table, we can find a weighted average of the 
ratings. The weighted average ratings are not very 
different than the average raw rating. The differential 
importance of different functions has not had much effect 
on the choice of system. 
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The formal evaluation then reinforces judgements less 
Eormally derived. The Dataphase proposal does not have the 
top score in any function and its average score is less 
than marginally adequate. OCLC's proposal does not top any 
category, but several of its functions are acceptable. 
When Dataphase has a public access catalog, serials and 
acquisition system and when OCLC has a serials and 
acquisition system, then they will become competitive. Our 
rating reflects the systems as they are available to assess 
in the time frame we targeted. 

The GEAC and NOTIS proposals are close in the formal 
evaluation. GEAC is at least marginally adequate in all 
but authority control and NOTIS is better than marginally 
adequate in all categories. GEAC's -strength is in 
circulation and in the level of responsibility assumed by a 
turnkey vendor. NOTIS's strength is in its catalog, 
serials, and authority control. its weakness is in 
support. Northwestern provides less software support and 
assumes less responsibi lity than a turnkey vendor . of 
course. Northwestern and GEAC also continue to develop 
their products. GEAC has improvements in authority files 
in development as well as in added capabilities. NOTIS 
plans improvements in circulation, acquisitions, and search 
systems . 

Looking beyond this formal evaluation of functions, we 
consider the success of the systems in libraries of the 
size and character of our own. And we look at the price. 
These factors lean markedly toward Nor thwes tern * s system. 



EKLC 



65 75 



SUHHARy EVALUATION OF VENDOR PROPOSALS 
Heard Library, August, 1984 







DATA PHASE 


DATA PHASE 


GEAC 


GEAC 


NOTIS 


NOTIS 


OCLC 


OCLC 






Raw Rating 


Weighted 


Raw Rating 


Weighted 


Raw Rating 


Weighted 


Raw Rating 


Weighted 
























7 






/ 


ltd 


0 


36 


2 


14 


Add CaD* 


3 


4.5 


13.5 


7 




a 

0 




0 


1 0 

Id 


Authority 


9 




18 


4 


36 


9.5 


85.5 


8 


72 


Cataloging 


9 




36 


7 


63 


9 


81 


6 


54 


Circulation 


10 




60 


9.4 


94 


8 


80 


4 


40 


HIS 


4 




8 


8 


32 


8 


32 


6 


24 


Search 


10 




10 


8 


80 


8 


80 


4 


40 


Serials 


9 




9 


6.5 


58.5 


8 


72 


1 


9 


Support 


10 


8 


80 


8.4 


84 


6.5 


65 


7 


70 


TOTAL 


71 


30.5 


248.5 


65.3 


517.5 


73 


575.5 


44 


341 


WEIGHTED 




















AVERAGE RATING 






3.50 




7.29 




8.11 




4.80 


RAW AVERAGE 




















RATING 




3,39 




7.26 




8,11 




4.B9 










DATA PHASE 




GEAC 




NOTIS 




OCLC 



Rating of 10 means meets all requirements 
5 means marginally adequate 

1 means meets none of requirements ^ / 

76 



ERIC 



VANDERBILT UNIVERSITY 



Note to Reviewers about Final Ratings Table 

The table reports ratings slightly different than those 
of the individual subcommittees. We have adjusted some of 
the ratings to reflect information that came to light after 
the committees had completed their tasks- We have also 
made some adjustments to reflect our own j udgr-nent about 
features of the various systems. In particular, we have 
given emphasis to the elegance of a unified bibliographic 
file as compared with the lesser convenience of linked 
files for acquisition, circulation and catalog; to the 
likely superiority of a report generator in supplying 
management information; and to the length of time required 
to load the database. Where a committee other than the 
support committee took account of the likely level of 
support of the system in assigning a grade to a function, 
we have changed the committee's score to reflect just the 
features offered in the given function. These changes in 
ratings did not change the rank order of the vendors in 
ei ther the raw or weighted f orm . 
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IMPLEMENTATION AND OPERATION OF LINKED/INTERFACED SYSTEMS 
AT THE LIBRARY OF THE UNIVERSITY OF ILLINOIS AT URBANA-CHAMPAIGN 

Sha;:or\ G, Clnrl^- 
COMPONENTS of the SYSTEM 



LCS 

The Library of the University of Illinois at Urbana-Champaign 
(UIUC) has had an automated circulation system since 1978 when the 
Library Computer System (LCS) was installed. LCS was developed by 
IBM in the late 1960's for installation first at Ohio State 
University in 1970, and then for the State University of New York 
at Albany in 1973. LCS was substantially modified prior to 
installation at UIUC to expand its potential from a 
single-institution environment to the broader multi-institutional 
concept envisioned in Illinois to support resource sharing . 

Primarily used for known item searching, circulation and resource 
sharing among 27 academic libraries in Illinois, each library in 
LCS maintains it s own data base of short records containing the 
following information: call number, main entry, title, edition, 
place of and date o£ publication, LC card number, language code, 
format code, and detailed holdings information by copy and 
location. LCS can be searched by author, author/title, title, and 
call number (both direct and shelf position) . It serves as the 
master shelflist, the on-order file and only record of current 
location. LCS is a full inventory-based circulation system, 
making the combined holdings of 15 million volumes of 28 academic 
libraries available on over 650 terminals throughout Illinois. 



FBR 

The second component of the public online catalog is called FBR 
(Full Bibliographic Record) , and is based on the software of WLN 
(Western Library Network) . Operational since August, 1984, the FBR 
database contains nearly one million complete MARC records 
representing the combined collections of UIUC and the Riverbend 
Library System since 1974 when OCLC was adopted for cataloging. 

Since it*s introduction in 1984, FBR has replaced the card catalog 
at UIUC, offering all of the traditional card catalog access 
points, with the exception of the call number (i.e. author, title^ 
subject, series, author- title) as well as being accessible by 
keyword in title, keyword corporate author, ISBN, ISSN, and 
through boolean logic. Authority control is provided through a 
separate and searchable authority file containing the Library of 
Congress name and subject files as well as authority records 
created from all items cataloged at UIUC (see appendiices) . 
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While FBR contains records for monographs, serials and 
audio-visual materials, formats not yet in FBR include: 
manuscripts, music, maps, sound recordings and newspapers; neither 
Ovj.-jt?: FBR include records for Chinese, Korean, Japanese, Hebrew, 
'./etsian or Armenian languages. 

FBR also contains a holdings file which enables a display of all 
librai'ies which hold a specific item. Currently, this feature is 
a useful searching aid in determining which recotds belong to UIUC 
and those held by the River Bend Library System, This feature 
will become increasingly important with future expansion of the 
Online Catalog on a statewide basis. 

In a major software development effort, a "link" was created to 
enable access to these two separate systems, LCS and FBR, from a 
single terminal. With ease, the user may move from the Full 
Bibliographic Record to its corresponding LCS record for call 
number, location and circulation status information. It is the 
Link which has enabled the online catalog to transcend its 
predecessors, placing at users disposal the capacity for 
bibliographic searching, authority control, circulation status and 
document delivery all from the same terminal. Further, the Link 
has not been responsible for any degradation of LCS response time 
or efficiency. Installation of the Link only involved minimal 
modification of WLN Software - thereby ensuring full participation 
and benefit from any future software changes made by WLN. (1) 



USER FRIENDLY INTERFACE 

In order to circumvent the need for user-proficiency of two 
different command structures of the LCS and FBR components of the 
online catalog, a user-friendly interface was developed by 
Professor C.C. Cheng of the Linguistics department at UIUC. Using 
natural language, the menu driven interface queries the patron and 
translates patron responses into the command languages of both 
systems . 

Public reaction to the interface has been exceedingly favorable 
since its first introduction on an IBM Personal Computer in March 
1983. At that time, development was in its first stage and 
limited to LCS^ but with ^ popular feature: automatic campus 
searching of all \2S databa.^.s. Currently there are approximate*;; 
60 IBM PC termin.:'!.s for public use at UIUC and the interface 
incorporates both FBR and LCS components of the Online Catalog. 
At UIUC, the interface resides on cassette tape inside the PC 
terminal, and is loadecl by tape player as these terminals were 
purchased without disc drives. Loading consumes five minutes but 
only occurs when a new versipA is distributed or it is 
interrupted due to a power failure. (2) 
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The interface has proven to be a resourceful response to both 
technical and user concerns. Use of natural language, and prompts 
greatly facilitates user access to the broad and powerful 
capabilities of the online catalog, while at the same time 
reducing the staff burden of training users in the use of separate 
systems. A positive impact on interlibrary borrowing has been 
realized as the interface has made this process easier and more 
direct for the patron. in a study of interlibrary borrowing 
activity since the first installation of the interface on an IBM 
PC in 1983, Potter reports a dramatic increase of nearly 3-fold in 
UIUC interlibrary borrowing from the LCS network of academic 
libraries. (3) 

The technical advantages cannot be overlooked, many of which 
formed the basis for implementing this approach as opposed to 
designing the interface for use on the mainframe computer which 
resides at the University of Illinois computing center at Chicago. 
Interaction at the local level ensures that only correct and 
complete messages reach the mainframe. All of the processing is 
confined within the PC program in each terminal, eliminating 
interference among terminals. This contributfs to maintaining 
fast interaction with the mainframe. The program also routes as 
many inquiries as possible to LCS since LCS is cheaper and faster 
to use than WLN and is able . j efficiently handle the majority of 
inquiries which are of the "known-item" type. Finally, the 
interface can be modified as desirable to respond to changing 
local needs, both technical and user-based in a timely fashion. (4) 



MAINTENANCE 

The cycle of growth for the Online Catalog database involves OCLC 
as the source of cataloguing, the weekly loading of the OCLC 
archival tapes and creation of the link between associated fbr and 
LCS records by University of Illinois programmers. Subsequent 
maintenance is handled locally in the Library's Automated Systems 
Unit. The majority of changes to LCS and FBR are accomplished in 
batch mode. LCS and the link file maintenance use a modified text 
editor called SUPERWYLBUR, and two data sets: UPDATES and 
HOLDING. Bibliographic and copy information are changed in the 
UPDATES file whereas modifications to monographic series and 
serial holdings are made in the HOLDING file. 

The more sophisticated and complex WLN programs are used to 
maintain the FBR component of the Online Catalog. Several files 
are available for online access including: the Bibliographic 
File, the Authority file, the Holdings File and Working File. 
Using the WLN Input/Edit facility and the Input, Change, and 
^f?^^^ subfiles of the Working File, new database records may be 
added and existing records modified or deleted. in addition, 
records added to the database from tape are reviewed. Most of the 
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FBR maintenance activity of modifying or deleting bibliographic 
and authority records in the database occurs in the change 
subfile. Within the Input/Edit facility , a multi-level review 
process exists as a quality control measure. 

The batch program for FBR (BIBVRO) runs twice weekly although it 
call )e run each night upon request. Routine back up of workfile 
is provided six nights each week and backup of the entire database 
occurs on a weekly basis. 

In an effort to further streamline the maintenance process, 
several programs have been written and implemented utilizing 
micro-computers. These programs have had an impact on all 
segments of maintenance by reducing the labor-intensive process of 
manual review. For example, in the case of unlinked records, the 
program is designed to automatically search FBR and LCS for 
possible links. Successful matches are stored on diskette for 
batch loading. Only a small number number of non-matches require 
manual searching and verification and in most cases only on LCS 
which is fast to use and thus efficient. (5) 

ACQUISITIONS 

The UIUC Acquisitions/accounting system operates separately on a 
minicomputer in the Library. Utilization of this 

minicomputevr-based system results in a file of order rec-^rds v/hich 
are loaded periodically into LCS. In this way, the LCS n-.^dule of 
the Online Catalog provides access to and circulation status not 
only of short bibliographic records for already catalogued titles 
but information about titles that have been ordered. Saves may be 
generated on LCS by patrons for books on-order. As books are 
received in acquisitions, order records are changed to reflect 
that items have been received and routed for cataloging. When the 
books have been cataloged, the OCLC catalog records overlay and 
replace the order records. At this point, any books which have 
had saves placed on them via LCS are routed to the appropriate 
patrons, while the others are sent to one of 35 library locations 
or centra 1 stacks . 

This approach has real advantages in terms of future development. 
Should the library decide to replace the current 

minicomputer-based acqui?.! tions/accoun ting system, changes would 
not be required to the Online Catalog. Rather, changes would be 
limited to only the programs and file formats used to create the 
order record for input into the Online Catalog. (6) 

SERIAL CHECK-IN 

Serial check-in ? ..resents another area conducive to linking two 
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systems in batch mode. At UIUC, serial check-in has been 
accomplished by combining LCS with micro-computers for check-in. 
Called "CHECKiMAN/' this locally developed microcomputer program 
deceives "fools LCS into behaving as if it were a check-in system" 
(BP, ital.p.314). Alternatives to CnECKMAN are currently under 
investigation including an independent check-in system. Such a 
system might involve microcomputers and periodic loading of 
information on the most current issue received into the LCS 
component of the Online Catalog. Using this information to create 
an updated status line for a serial in the LCS record would keep 
users informed as to receipt of current issues. In the LCS 
record, information on unbound issues would be displayed directly 
above information on bound volumes. 

While a new serial check-in sy^cim will not be implemented until 
January, 1987; the search for the best available system for this 
particular function has been made possible by what we have learned 
about linking . 

The advantage of linking systems by transfer of information on a 
batch basis is that performance of the Online Catalog has not been 
compromised anc? yet current status information on materials in 
technical processing is provided. 

Based on the UIUC experience with linking, other academic libraries 
using LCS will benefit from the advantages this approach offers, 
namely: 

(1) a library is not tied to one vendor or source 

(2) a library can shop for the best available 
system for each function, and 

(3) the interaction among functions is kept to a 
mi nimum and the performance of one does not 
affect the performance of another (7) 

This approach to linking is consistent with a recommendation 
recently made by a committee of librarians representing the LCS 
network of 27 academic libraries in Illinois. Charged with 
investigating alternatives for circulation and resource sharing in 
Illinois, the committee supported the 1) continued use of LCS 
based on it's cost-ef f ec tivenes.^ and proven performance in ability 
to maintain consistently the high level of current activity and 2) 
expansion of the FBR component of the Online Catalog to the other 
LCS libraries for operational use. This committee also 
recommended that automation of acquis it ions and serial check-in be 
based on local systems but that a common format be developed for 
transferring status information from the local system into LCS. (8) 
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FROM IMPLEMENTAT I ON TO OPERATION 

A network governance structure evolved to guide the expansion* of and 
development of LCS. In the spring of 1980 the Illinois LCS 
Organization (ILSCO) was formad. The Policy Council is composed 
of six elected directors who address matters of policy and monitor 
resources. The ILCSO Operations Committee includes one 
representative from each participating institution^ as well as 
non-voting representatives from University of Illinois 
Administrative In formation Systems and Services . This working 
group addresses technical issues and has coordinated development 
of specifications for system enhancements ^ through subcommittees. 
Policy Council meets monthly while the Operations Committee meets 
bi-monthly. m addition^ all Library Directors of LCS 
participating institutions meet twice annually. 

Just as LCS expansion had its impetus from state funds to form the 
basis for a computer based library network to aid resource 
sharing^ FBR was supported by Library Construction and Services 
ACT (LSCA) funds administered by the Illinois State Library to 
demonstrate the feasibility of a statewide union catalog. A 
series of committees were formed to guide it^s development^ 
including policy and Implementation^ Technical^ Steering and User 
Education. 

Administration of the Online Catalocj has changed only slightly 
since the Online Catalog became fully operational. A Library 
Online Catalog Advisory Committee exists to address issues 
concerning all of the components,, and Technical Committee members 
deal with technical matters. Two Coordinator positions have been 
created: one to handle operations and development and the other to 
coordinate user training (se*? appendix). 

To handle statewide expansion of the Online Catalog^ a statewide 
Online Catalog Advisory Comn;ittee was formed to advise on issues 
related to creating an online union catalog for Illinois. 



FUTURE 

STATEWIDE UNION ONLINE CATALOG 

In 1985^ funding was requested and received to expand the data base 
of this joint catalog to provide an ILLINET Online Union Catalog, 
based on the OCLC cataloging records from ILLINET member 
libraries. The ILLINET Online Union Catalog would contain over 
3,000,000 titles reflecting over 10,000,000 holdings and would be 
accessible through terminals in each of the Regional Library 
Systems, in the Reference and Research Centers, in the LCS member 
libraries, and through dial-up access. The objectives necessary 
to meet this goal are 1) provide a feature to limit searching by 
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Regional Library System or by library; 2) imp^ ic the latest 
version of the Washington Library Network sott^ .; and 3) load 
all available ILLINET OCLC records. This pr . "^^^^ would take two 
years to complete and evaluate. 

The proposed ILLINET Online Union Catalog would provide full 
bibliograp::iic access — author, title, subject; series, etc. — to 
all titles cataloged on OCLC by ILLINET member libraries. It 
would also rTSsist cooperative collect ion development efforts by 
providing biblicqr?.phic access to cooperative col lections 
cataloged througii OCLC. 

The creation of an ILLINET Online Union Catalog would greatly 
enhance resource sharing efforts in Illinois. It would also 
complement three other efforts currently underway: 1) the various 
projects to link or "interconnect" the local automated systems at 
the Regional Library Systems; 2) the development of an IBM PC 
based interface between the RBLS/UIUC Online Catalog and automated 
library systems at three Regional Library Systems; and 3) various 
efforts aimed at improving cooperative collection development 
efforts. 

Several projects allow staff at one Regional Library System to 
dial into the automated system of another Regional Library System 
to determine the availability and status of a given item for 
interlibrary loan. This is a much needed program that promotes 
library cooperation and resource sharing in the state. However, 
it requires searching up to 17 other syste i with up to three 
different search languages. Also, it is restricted in that some 
systems <lo not yet offer subject access and few offer keyword 
searchi The ILLINET Online Union Catalog will provide a way to 
search ^ n.aster file with holding? records for ILLINET libraries 
that use OCLC and will reveal which of the Regional Library 
systems owns the desired item. It will also provide precise 
information for retrieving the- circulation record from the 
automated system in use at a given Regional Library system. 



CIRCULATION SYSTEMS INTERFACING VIV.C CATALOG AND PUBLIC 

The ongoing interface project would take the above process a step 
further. This project is developing an interface based on an 
IBM PC that is connected both to the RBLS/UIUC Online Catalog and 
to the local automated system in use at each of three Regional 
Library Systems — Lincoln Trail Library System, Cumberland Trail 
Library System, and Lewis and Clark Library System — Lincoln 
Trail Library System uses CLSI, Cumberland Trail Library System 
uses Data Phase, and Lewis and Clark Library System uses Data 
Research Associates. This project allows an operator to search 
two systems simultaneously from the same terminal. For example, 
the operator might be looking for a book with a specific title. 
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Thi> interface program will ask for the words in that title and 
then search the local system first. if the title is not found, 
the interface program can be used interchangeably to search the 
RBLS/UIUC Online Catalog. The same approach will be taken for 
other types of searches — author, subject, series, etc. 

While the current project calls for pairing the RBLS/UIUC Online 
Catalog to only one of the local automated systems at a time, 
future development might include an extension that would insert an 
automatic dialing device into the IBM PC permitting access to any 
of the other systems. Thus, an operator at Cumberland Trail 
Library System could access the RBLS/UIUC Online Catalog, find a 
desired title, and retrieve the circulation record from the Data 
Phase system in use there or from the CLSI system at Lincoln Trail 
Library System or from the DRA system at Lewis and Clark Librnry 
System. This would be done by having the IBM PC store the OCLC 
number £or the desired item, dial into one of the other systems, 
and search for a record using that OCLC number. if the OCLC 
control number did not work, the ISBN or some other number could 
be used. in a true ILLINET Online Union Catalog, the titles owned 
by each of these three Regional Library Systems would be stored in 
the union catalog data bas3 and the OCLC number could form the 
basis for retrieving the circulation record from any other system 
using OCLC as a source of records for its local system. 



OPTICAL DISK CATALOG 

Another project sponsored with LSCA funds involve? research into 
creating and demonstrating an optical disk ' of the 

bibliographic data base of the UIUC/River h^rv^ \Aorary System 
Online Catalog. Using curr- "1 chnology , MAhC records on machine 
readable magnetic tape wou; • :-^r used to create a catalog based on 
an optical disk that can b'f - ^.-^i by microcomputer, with searching 
by key word possible anywh - c v : if the MARC record. This approach 
promises fast response tim.: . u the capacity to store one million 
MARC records on only two dis.-... When this project is completed, 
the optical disk catalog wxll be demonstrated at the Library of 

University of Illinois at Urbana-Champaig n and at one of 
-..ghteen Regional Library System headquarters in Illinois. 

If successful, this project will make feasible the next stage — the 
preparation of an optical version of thn statewide union catalog 
for distribution throughout Illinois enhance resource sharing. 
Even though the mainframe version of the illinet Union Catalog 
would be preferred for maintenance, auchority control and 
currency, an optical disk alternative would be highly attractive 
for locations unable to afford the telecommunications cost of the 
mainframe-based system. Multi purpose use of the equipment 
connected with an optical disk catalog to include other databases 
is also advantageous. 
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PROJECT EXCEL 

Project Excel involves t'of2 development of a microcomputer 
interface to enable Library users, primarily students to 
effectively access citations to periodical literature contained in 
the various commercial online bibliographic databases. The 
interface is being designed to replace the traditional skilled 
intermediary, thus allowing the end user direct access without a 
need for either orientation or training. Through this pilot 
project which will be tested at UIUC Library sites serving a large 
undergraduate population, users will have enhanced access via 
public IBM PC terminals equipped with the interface to a majoj. 
segment of the Library's collection which is not currently 
available in the online catalog. 

The software for this experiment is based upon a microcomputer 
communications package designed two years ago by William Mischo. 
Called Illinois Search Aid, it has been used in six Library units 
to aid librarians in providing mediated online searching services. 
Through Project Excel, a customized version of the original 
interface will provide for the formulation of offline interactive 
search strategies as well as the linking of search results to the 
UIUC Online catalog for holdings and availability information. 
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Operating Environ^ nent 



The TRLN Libraries 

The libraries of the three TRLN institution.';, while similar 
in many respects, also have significant differences. 
Organizationally, Duke and UNC-CH both include separately 
administered libraries, which are funded separately from the main 
academic library system and create their own cataloging records. 
To provide for particular cataloging requirements of some special 
collections, UNC-CH also includes cataloging centers that are 
administered within the main library but establish their own 
cataloging procedures. However, cataloging policies are 
coordinated among all participants in TRLN, with the goal of 
creating a consistent catalog system without sacrificing the 
flexibility needed to support specialized local collections. 
Thus, for example, detailed holdings are represented in the same 
way for everyone, but the system supports several classification 
systems and subject heading authorities. 



The Software Env'ronment 



TRLN systems are modular in design, with each module 
concerned with a specific system function. For example, command 
interpretation is handled in one module while retrieving records 
from the data files is handled by another. The modules 
communicate v/ith each other interactively, using the interprocess 
communication facility provided by the Tandem operating system. 
This approach simplifies system maintenance since only the 
relevant module (s) must be changed when a function changes. In 
addition, especially in the Tandem environment, the modular 
-pproach allows greater flexibility in optimizing system • 
performance. 



TRLN software is written primarily in COBOL (the ANSI 1974 
standard), with some subroutines written in TAL (Tandem's system 
language). TAL is used v^hen specific features of the Tandem 
operating system (GUARDIAN) are needed that are not available 
through COBOL. All TRLN online systems are coded "NonStop" to 
take full advantage of Tandem's fault tolerant architecture. 

Tandem provides a number of software products in addition to 
the operating system and programming languages. Since most of 
these are aimed at typical business applications, TRLN has been 
unable to use them effectively in the online catalog. Instead, 
the online catalog has been implemented using only the more basic 
tools, Buch as the i;NSCRIBE file management system. 
Acguisii 3/ serials and circulation are more like traditional 
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data processing applicationsr and it is anticipated that many of 
Tandem's other software products will be appropriate and that 
their use will speed up the software development process. In 
particular, the ENFORM report generator and the PATHWAY terminal 
and screen management system are expected to be valuable in the 
ongoing development effort. 



The Hardware Environment 

The TRLN software is designed to operate on a distributed 
network of Tandem computers (either Nonstop II or TXP) , with 
separate installations at each institution supporting the online 
catalog system for that institution. This approach allows each 
institution to operate the particular configuration that best 
suits its needs and budget. The three systems will be linked, 
using Tandem's EXPAND software to provide networking services. 
However, until Duke and NCSU are able to install their own 
systf^msr the computer installation at UNC-CH will provide service 
for ail three installations. The UNC-CH computer also supports 
the TRLN development effort. 
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DEVELOPMENT ACTIVITIES: FIVE YEAR PROJECTION 



Notes: 



functions are shown during years that development work is in 
progress. The status indicates the stage of development in 
progress or completed at the end of the year. 

oi?nDc/?fo?^^^^^^'^^^ ^^^^^ available until fis--l year , 

Fyiy86/1987r and the schedules are quite general for ter years^ 
it is difficult to identify the effect of the additional s^^ff• 
Examples of the effect on major functions are: 

- the circulation functions will be ready by the end of 1987 
instead of near the end of 1988 

- the authority control system will be completed by the end of 
1989 rather than near the end of 1992 

- the serials/acquisitions system will be well into the coding 
stage at the end of 1989, Without additional staff, coding 
will not have begun on these functions by then. 



Option 1: Existing staff 



Option 2: Additional staff 



985 

unctions iindex 

Authority control: names 
(functional design in 
progress) 

OCLC Link 

(functional design and 
implementation design 
complete, coding in 
progress) 

Searching multiple TRLN 
catalogs simultaneously 
(implementation design 
complete, coding in 
progress) 

Circulation 

(functional design in 
progress) 

Serials/Acquisitions 
(functional design in 
progress) 



1985 

Functions iiad^X devglopment: 

Authority control: names 
(functional design in 
progress) 



OCLC Link 
(functional 
implementa^- , 
complete, c 
progress) 



design and 
J iSign 
in 



Searching multiple TRLN 
catalogs simultaneously 
(implementation design 
complete, coding in 
progress) 

Circulation 

(functional design in 
progress) 

Serials/Acquisitions 
(functional design in 
progress) 
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Lon Functions Ini^ lull Qperatloa 



**Basic searching^ database 
maintenancer and general 
support functions (BIS-1) 

♦♦Subject/Call number searching 
Alternative terminal support 



**Basic searching, database 
maintenance, and general 
support functions (BIS-1) 

♦♦Subject/Call number searching 

Alternative terminal support 



1986 

Uqm. functions b^aun 

Authority control: subjects 
(functional design in 
progress) 

Authority control: using 
cross references for 
access 

(functional design in 
progress) 

Functions unAsx development! 

Authority control! names 
(functional design 
complete) 

OCLC Link 

(coding in progress) 

Circulation 

(functional design and 
implementation design 
complete) 

Serials/Acquisitions 
(functional design 
in progress) 

Functions int^j lioll operahion 

♦♦Searching multiple TRLN 
catalogs simultaneously 



1986 

Hew functions iLfi^iiB 

Authority control: subjects 
(functional design in 
progress) 

Authority control: using 
cross references for 
access 

(functional design in 
progress) 

FunctionjB UluSfX developmeph 

Authority control: names 
(functional design 
complete) 



Circulation 

(functional design and 
implementation design 
complete) 

Serials/Acqui sit ions 
(functional design 
in progress) 

Functions Intst full os-OJLSLt ism 

♦♦Searching multiple TRLN 
catalogs simultaneously 

♦♦OCLC Link 
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1987 

SSM functions h&aan 

Enhanced searching 
(functional design 
in progress) 

ElinCtiPns irndex development 

Authority control 
(functional design 
completer implementation 
design in progress) 

Circulation 

(coding in progress) 

Serials/ Acquisitions 
(functional design 
complete) 

Functions in^ qs^^^^^^ 
**OCLC Link 



1988 

Usu functions hssan 

Management Information 
(functional design 
in progress) 

Functions iindfiX .development 

Authority control 

(implementation design 
complete^ coding in 
progress) 

Enhanced searching 
(functional design 
complete f implementation 
design in progress) 

Serials/Acquisitions 
(implementation design 
complete) 
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}is^ functions hss^m 

Enhanced searching 
(functional design 
in progress) 

Functions iind^j: development 

Authority control 
(functional design 
complete r implementat ion 
design in progress) 



Serials/Acquisitions 
(functional design 
complete) 

Function>3 intSt luU o peration 

**Circulat ion 



1988 

Us^ functions h^oim 

Management Information 
(functional design 
in progress) 

Functions Aind£X development 

Authority control 

(implementation design 
completer coding in 
progress) 

Enhanced searching 

(functional design and 
irnplementation design 
complete) 

Serials/Acquisitions 
(implementation design 
completer coding in 
progress) 




UNIVERSITY OF NORTH CAROLINA 
functiont? into, full pperation FunctionR jLatc full operation 

♦♦Circulation 



1989 

Functions iindfiX development - 

/authority control 
(coding in pi ogress) 

Enhanced searching 

(implementation design 
complete) 

Management Information 
(implementation design 
complete) 

Serials/Acquisitions 
(implementation design 
complete) 

F^nci:^onR Jjitfi fnl\ operatiion 



1989 

Functions imd£X developme 



Enhanced searching 

(implementation design 
complete) 

Man;:.gement Information 
(implementation design 
complete) 

Serial s/Acqui sit ions 
(coding in progress 

Functions IntSi lull operation 
♦♦Authority control 
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MIRLYN Implementation Plan 
c:\iiirlyn\iiiplan.Npf 



UNIVERSITY OF MICHIGAN 



March 27, 1986 



COMMITTEE STRUCTURE 



As the Library <noves to install NC3TIS the pro<.:£?5s of de-fining 
the Vc^rious table -filesi will require that ^^^e e!!':smine our policies 
and procedures. It is also the case that the i ntraduc!:i on of a new 
tool provides an opportunity to review policies, procedures, and 
workflow. The structure outlined below is the same? as that in the 
memo of Narcli 13, save -for a reduction in the number o-f Procedure' 
Review Teams. These committcses, along witli MAC will advise the 
Library administration. Final decisions will be made by Cabinet. 



CABINET 




POLICY REVIEH TEAK 
USER SERVICE/SUPPORT 



POLICY REVIEH TEAH 
STAFF TRAINING 



POLICY RHVIEH TEAH 
LOAN CODE 



POLICY REVIEH TEAH 

PROCESSING 

DB ADHIHISTRATIOH 



POLICY REVIEW TEAK 
AUTHORITY FILE 



ANALYSTS 
DUNKLE/DIXOH 



PROCEDURE REVIEH TEAH 
PROCESSING 
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MIRLYN Implementation Plan March 27, 1986 

c:\airlyn\iiplan.Hpf 



POLICY REVIEW TEAM 
PROCESSING - DATABASE ADMINISTRATION 



This committt?e is charged to review and recommend policies 
governing the processing of Library materie.1. Processing includes 
the acqusition of material, the creation of bibliographic records, 
the creation of holdings records, the physical preparation of 
material, mcUntenance of the online files, maintenance of card 
files, and quality control. Issues that should be addressed include, 
but are not limited to, tlie following: 

1. The bibliographic and holdings record structure 

2. The content of bibliographic and holdings records 

3. The content of .the MIRLYN OPAC. What "non-standard" files should 
be included in the OPAC and should they be added in a particular 
order, all at onece, or in some other way. Included in this 
category are materials such as slides, dissertations, etc. 

4. What should happen to existing card catalogs 

5. Should maintenance be performed on records in the card catalogs 
or should such v^ork be performed on MIRLYN 

6. Should maintenance of machine-readable records be performed on 
RLIN or MIRLYN 

7. Should the quality control program now in effect be used for 
MIRLYN as it now stands or are modifications required 

a. Should the procedures for reviewing the Geac record structure be 

used with MIRLYN or are modifications needed 
9. Whether indicators should be edited. 
•10. Whether headings shoul be flipped to AACR2 

11. Cataloging policy - for example, should bibliographic treatment 
be standardised for the same bibliographic enties? That is 
should we use a single call number for all copies of an item 
regardless of location? Should monographic series be treated 
the same regardless of location? Should mongraphic series 
catalooed as separates be checked in at the serials record? 

At what point should authority control be applied to entries? 

12. Acquisitions policy - for example, vjere should pre-order 
searching take place? Who should assign vendors? 

13. Serials policy 



The committee should produce a final report that contains 
detailed and explicit recommendations and draft palcies. 

Note that the specific charge to this committee may be modifie 
depending upon the content of the final reports of the first 
MIRLYN committee 
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MIRLYN Implementation Plan March 27, 19B6 

c:\airiyn\i(iplan.Hpf 

DEADLINE; AUGUST 1, 1986 

POLICY REVIEW TEAM 
CIRCULATION 



This committee is charqed to r'evievv end recommend policies 
governing the circulation of Library material. Circulation includes 
fine rates, holds policies, loan periods, and patron categories. 
Issues that should be addressed include, but arfs not limited to, the 
following: 



1. Should the fine rate be standardised throughout the system 

2. Should the hold policy be standardised throughout the system 

3. Should loan periods be standardised 

4. Who can register patrons 

5. The number of notices and the type of notices sent to users 

6. The wording of notices 

7. Who can assign privileges to patron categories 

8. What policies and procedures should be used ta handle material 
for which there is no machine-readable record 

The committee should produce a final report that contains detailed 
and explicit recommendations and draft polcies.. 

Note that the specific charge to this committee may be modified 
depending upon the content of the final reports of the first MIRLYN 
committee 

DEADLINE: AUGUST 1, 1986 



98 

86 



UNIVERSITY OF MICHIGAN 
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POLICY REVIEW TEAM 
AUTHORITY FILES 



This committee is charged to review and recommend policies 
covering the creation and maintenance of a machine-readable 
authority -file. Issues that should be addressed include, but are not. . •: 
limited to, the -following: 

!• How to build a machine-readable authority -file 

2, Whether headings should be -flipped to AACR2 

3, The specific source authority files that will be us=ied 

4, What unit or units will be authorized to maintain tlie authority 
file 

How the authority files will be updated 

Tlie committee should produce a final report that contains detailed 
and explicit recommendations and draft polcies. 

Note that the specific charge to this committee may be modified 
depending upon the content of the final reports of the first MTRLYN 
committee 

DEADLINES OCTOBER 1, 1986 
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POLICY REVIEW TEAM 
USER SERVICE/SUPPORT 



This committee is charged to review and recarnmend policies 
concerning the delivery of service to users of MIRLYH. Ihis includes 
educating users in the use of NIF^•LYN. recommt^ndinq the format of us«f 
docun^entation, recommending the content of user documentation, 
recommending the structure that will be U5F;?d to deliver service to 
MIRLYN users, both those in the Library and those at remote 
locations, such as offices, dorms, laboratories, and homes. Issues 
that should be addressed include, but are not limited to, the 
following: 

!• What user documentation will be required 

2. What unit or units should produce and m.=iintain the documentation 

3. How should the documentation be laved out 

4. What structure should be .used to deliver services to local and 
remote users 

The committee should produce a final report that contains detailed 
and explicit recommendations and draft polcies. 

Note that the specific charge to this committee may be modified 
depending upon the content of the final reports of the first MIRLYN 
committee 

DEADLINE: DECEMBER 1, 1986 
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POLICY REVIEW TEAM 
STAFF TRAINING 



This committee is charqed to review and recommend policies 
concerning the structure and content of staff training. Issues that 
should be addressed include, but are not limited to, the following:. 

1. Who should deliver staff training 

2. What should be the content of staff training 

3. How should training be delivered 

4. How should on-going training be provided 

5. What documentation will be required 

6. How should the documentation be layed out 

7. Who should produce and maintain the documentation 



The committee should produce a final report that contains detailed 
and explicit recommendations and draft polcies. 

Note that the specific charge to tliis committee may be modified 
depending upon the content of the final reports of tha first NIRLYN 
commi ttee 

DEADLINE: SEPTEMBER 1, 19S6 
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PROCEDURE REVEIW TEAM 
PROCESSING 



This committee is charged 
"blueprint'* -for the structure 
University o-f Michigan Librari 
of material, the creation o-f b 
holdings r'ecords, the physical 
of the online files, maintenan 
The committee should review ex 
workflow across all units and 
of MIRLYN will enable the Libr 
committee should produce a det 
tasks and the unit(s) in which 



to review and rec 
of processi nu mate 
es. Processing inc 
i bl iographi c recur 

preparation of ma 
ce of card f i 1 es , 
i sting processing 
shoul d r ecommend h 
arv to reconf igur 
ai 1 ed report that 

they shoul d be pe 



ommend a new 

r i ai wi th i n the 

ludes the acqusition* 

ds, the creation of 

ter-i al . maintenance 

and quality control.. 

procedures and 

ow the introduction 

processing. The 

i dent i f i es processi ng 

rf ormed • 



Note that the specific charge to this committee may be modified 
depending upon the content of the final reports of the first MIRLYN 
commi ttee 



DEADLINE: 



MARCH 1, 1987 



The analysts (Dunkle and Dixon) would have three broad 
responsibilities. First, they, would be responsible for completing 
the mechanical tasks that are* required for NOTIS to operate. Second, 
they would be responsible for informing the Policy Review Teams and 
the Procedure Review Team of the information they require 
NOTIS. That is, they will need to specify the information 
teams will need to provide. And third, the analysts would 
avai lab le as techni cal consul tants. 



to install 
the various 
be 



In addi t i on to the Li brary wi de i ssues contai ned i n the 
committee charges, a subset of issues will need to be considered at 
the divisional and unit level. Decisions that fall into this 
category include: 

1. distribution of terminals ' 

2. distribution of printers 

3. di str i bution of barcode readers 

4. definition of privilege levels for staff within the unit 
(consistent with Library wide policies) 

5. revision of unit pol ici es, procedures, and workflow 



EKLC 



102 



90 



System and Procedures Exchange Center 



Operation 

Computer Center Relations 
• System Description 
• Use Statistics 
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UNIVERSITY MICHIGAN COMPUTER CENTER RELATIONS 



Narch 27, 1986 



PROPOSED 
SERVICE AGREEMENT 
BETWEEN THE UNIVERSITY LIBRARY SYSTEM AND THE COMPUTING CENTER 

(version 4) 



1.0 OVERVIEW 

The University Libraries, along with the Law Library, the Kresge 

Business Library and the Flint Library, intends to replace its 

ei:i sting stand-^alone automated systems with i\n i nteqr ctt ed software 

package. The package will support (1) an online catalog, (2) 

acquisitions, (3) record management, (4) circulation, and (5) 

serials control. The system will run on an IBM 4381/2. The initial 

implementation of of MIRLYN (Michigan Research LibrarY Network) will 

support 575 concurrent users and a database of 4.75 million 

bi bl i ocjraphi c records. Acess to MIRLYN will be provided through e 

netviork of 300 terminals and through UMnet. 

The Library will own the hardware, software, and data for MIRLYN and 
retain5> exclusive right to tine use of all three. The Library 
desires, by this agreement, to contract with the Computing Center 
fur operation of the syste(n. 



1 . 1 Purp ose 

Tfiis agreement is intended to define (1) the services l:liat will be 
provided by the Computing Center, (2) the responsibilities of both 
the Library and the Computir^g Center, (3) standards of performance, 
and (4) procedures for the resolution of performance problems. 

The successful installation and operation of MIRLVN will require a 
cooperative partnership among the Library, the Comuutinq Center, and 
the vendors • This agreement provides the foundation for such a 
cooperat i ve effort • 

2.0 UNIVERSITY LIBRARY RESPONSIBILITIES 
The Univesity Library shall: 

2.1 Purchase the central site liardware (processor, console, diesk 
drives, tape drives, and printer) necessary to 'support MIP^LYN 
and will pay the maintenance ori the equipment. 
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2.2 Purchc»5e. install, and maintctin the? te?rminal devices, terminal 
printers^, and barcode readers used with the MIRLYh4 system. 

2.3 pLirclTc^se tlie necessary communicat ians hardware to connect 
MIRLYN to UMnet and pay the maintenance on the equipment. 

2.4 Obtain the license -for the NOTIS software and conversion 
programs necessary to run the NOTIS system and load the 
Library's machne— readab 1 e data. 

2.5 Pay all charges -for the installation and maintenance of the 
NOTIS software. 

2.6 Provide the application programmer (s) necessary to install .>nd 
maintain the NOTIS software. 

2.7 Provide the necessary supplies for operation of the system 
including, but not limited to, paper, formss, and magnetic 
tapes. 

2.8 Pay the installation, license, and annut?l charges for the 
system software needed to run NOTIS. 

2.9 Pay tlie installation, license, and annual charges for the SAS 
Insititute report writing software. 

2.10 Provide for the training of Library staff for the in<3tal 1 ati an 
and operation of the NOTIS system, including handling daily 
consulting regarding use of, the system. 



3.0 COMPUTING CENTER RESPONSIBILITIES 

The Computing Center shall provide the following services: 



3. 1 Systems Pr ogr ammi nq 

The Computing Center shall provide a systems programmer and shall be 
responsible for: 



installation of the central site hardware 
selection and installation of the operating system 
installation of the applications packages 
maintenance of the operating svstem 
troubleshooting hardware and software problems 
in conjunction with the hardware maintenance vendor, 
maintain the hardware 



ERIC 



1Q6 



92 



UNIVERSITY OF MICHIGAN 

r:>F:PiF*T March 27, 1986 

ilsulcc.Hpf 



3- 1- 1 Staffing 

Staffing for the first nine months of the project will be at 1 FTE. 
Thereafter ,5 FTE will be allocated to the project, 

3-1.1.1 Charges 

Charges shall be negotiated annually. 



3- 2 Operations 

The Computinq Center shall provide computer operators c^nd shall be . 
responsible for the following tasks according to schedules 
established by the Library- 

1. bringing the system up and down 

2- backing up files 

3. running batch jobs 

4- distributing, printed output . 

5. maintaining c^n operations log 

6. mounting tapes 

3.2. 1 Staffing 

1 FTE operator will be assigned to the project, 
3-2-2 Costs 

Charges shall be negotiated annual ly- 



3-3 Network Support 

The Computing Center shall define how to connect MIRLYN to UMnet and 
shall assist in the maintenance of the connections 



3-4 Q t h e r S e r V i c e s 

3-4.1 The Computing Center shall obtain the licenses for the system 
software and the SAS Institute software. 

3-4.2 The Computing Cen.ter shall house the MIRLYN backup tapes. 

2-4.3 The Computing -Center shall arrange for maintenance for the 
central site hardware. 



4.0 PERFORMANCE MEASURES 



EKLC 



UNIVERSITY OF MICHIGAN 

r>F5ftF"^r March 27, 1986 

ilsulcc.npf 



MIRLYN will play a central and critical role in the Libraries 
abilities to meet its commi tttnents to the University cofrmunity. The 
online catalog is the principal product of the Library and i-f it is 
not available it is the equivalent of closing the Library. Behind 
the scenes^ steady productivity is necessary in order to maintain 
the efficient catalog creation and maintenance that form the 
foundation of Library activities. Excellent system reliability and 
response time are necessary in order to effectively maintain 
productive workf low. 



4.1 System ftvai lability 

The online catalog must be available 24 hours a day, save for 
scheduled maintenance periods. 

The acquisitions, serials control, circulation, authority control, 
and record maintenance systems must be available from 0700 to 0200 of 
the following day seven days a week. 

The Libraries will regularly supply the Computing Center with a 
detailed calendar that shows exceptions in which service is not 
required due to holidays* 

The availability schedule may only be changed bv the Library, 



4.2 Response Time 

4.2.1 Definition 

Response time is defined as the time period between the moment * an 
ENTER command is sent and the moment the first character in response 
to that command is displayed on the terminal. 

4.2. 2 Performance Measure 

Response time for 95X of the responses must average no more than two 
seconds -for all transactions except keyword and boolean searches 

Response time for any individual transaction, except keyword and 
boolean searches, must not exceed f i ve seconds 

Response time for 95/C of the responses f keyword and boolean 
searches must average no more than -five .>econds 

Response time for any individual keyword or* boolean searche must not 
exceed 10 seconds 
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4.2.3 Measurement and Reporting. 

The Libraries and the Computing Center will v/ark togethrar to use 
appropriate measuring devices and record keepinq techniques to 
monitor response time performance. 



^ ■ -3 Dot^mt ime 
3.3.1 Definitions 

TOTAL SYSTEM DOWNTIME = sum of dovvntime factors divided by the sum 

of daily operational hours 

DOWNTIME FACTOR = downtime hours multiplied by the downtime 

coefficient as defined in section 3.3.2 of this 
section 



DAILY OPEf^ATIONAL HOURS = those hours (1) that a specific 

subsystem is scheduled to be available 
and (2) the system is scheduled to run 
overnight batch lobs. Regularly scheduled 
preventive maintenance is excluded from 
the calculation of daily operational 
hours. 



DOWNTIME HOURS = that period of time during which various parts of 

the systeni are unusable due to hardware or 
software malf uncti on or f ai lure. Downtime hours 
for each incident shall be measured ' duri ng the 
performance period as the time between the time 
the University pf-Jlichigan Libraries and 
Computing Center makes a bona f i de attempt to 
contact the maintenance vendor and the time the 
system is returned to the University of Michigan 
Li brar i es in proper operati ng condi t i on n provi ded 
that all hardware that the maintenance vendor 
deterniines necessary to test the hardware are made 
available to the maintenance vendor at his 
request. If initial hardware or softwcu'e 
malfunction or failure occurs during unattendtid 
overnight batch process i ng , calcul ation of 
downtime hours may commence one liour before 
discovery of the malfunction or failure 



During a period of downtime, the University of Michigan Libraries may 
use operable hardv^are/sof tware when such action does not interfere 
with maintenance of the inoperable hardware/software 



4.3.2 Downtime Coefficients 
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4.3.2.1 Systems Software 

4.3.2.1.1 operatina system 1.00 
(including DBMS 

4.3.2.1.2 system utilities 0.50 



4.3.2.2 Hardware 

4.3.2.2.1 Central processing unit 1.00 

4.3.2.2.2 disks, if system isi not operational l.OO 
(i.e. if data is not available) 

4.3.2.2.3 disks, if system is operational 0.10 
and all data is available - 24 hour 

grace period 

4.3.2n2.4 tape drives, if alternative 0.10 
backup is available - 24 hour 
grace period 

4.3.2.2.5 tape drives, if no altcrnotive 1.00 
bac kup i s avai 1 ab 1 e 

4.3.2.2.6 system printer 0.75 

4.3.2.2.7 other hardware failures or 0.10 
malfunctions 



4.3.3 Performance Measure s 

cDowntime of entral site and communications components of the system 
must not exceed 27. during a 30 day period. 



4.3.4 Measurement and Reporting 

The Libraries and the Computing C 
appropriate measuring devices and 
moni tor downti mee. 

4.4 Problem Resolution 

When system performance does not 



enter will work together to use 
record keepi ng techniques to 



meet the standards defined above 
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the Libraries and Computing Center v^ii 1 1 jointly work to (1) identify 
the cause o-f the problem and (2) work to resolve the problem. 



5.0 SECURITY 

The Cofnputinq Center will take all r-easonable measures to insure tht? 
inteqri ty and security of MIRLYN progri'.ms and data. The Computing 
Center further war*r £\nts that al 1 data and programs i nstal 1 ed on the 
systeni will be maintained as confidential by the Computing Center. 
r*4o data or pr*ograms may be transmitted to a tfiir*d party by the 
Computing Center without the written permission of tlie Libraries. 

6.0 ACCOUr-iTABILlTY 

The Computing Center warrants that all reasonable measures within 
the resources of tlie Computing Center shall be taken to insure the 
availability and integrity of the MIRLYN system. In the event of 
temporary staff shortages, svstem failures, or other unforseen 
problems, all appropriate steps shall be taken by the Computing 
Center to maintain operation of the system. The Computing Center 
assumes responsibility for any errors that may be made by Computing 
Center staff assigned to the system and will effect correction of 
any such errors. 



7.0 RENEWAL, MODIFICATION, OR TERMINATION OF AGREEMENT 

This agreement shall be renewed on an annual basis, but may be 
modified, amended* or terminated, at any time by mutual agr-eement of 
the Director of the Computing Center and the Director of the 
Libraries. 



a.O PROJECT MANAGEMENT 

The University Library and the Computing Center shall each designate 
an individual to serve as project manager for eacTi organization. 
These two individuals shall have responsibility for implmementting 
this agreement- 



THIS AGREEMENT IS EXECUTED BY: 



THE LIBRARIES THE CaNRUTING CENTER 
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COMPUTER CENTER RELATIONS 



AGREEMENT RELATIVE TO RESPONSIBILITIES TO IBM 4 361/LIBRARY 



This document records the general agreement between the 
Heard Library and the Computer Center relative to the 
responsibility and funding of the IBM 4 361/NOTIS Computer 
System 



RESPONSIBILITY 

A. Jean & Alexander Heard Library 

1. Provide funding for the hardware, software, 
maintenance, operations, supplies and other 
support as needed for the IBM 4361 

2. Scheduling 

a. Availability of IBM 4361 system to users 

b. Special jobs session by Library personnel 
or VUCC Operators via a RUNBOOK 

3. Special forms will be ordered initially by the 
Library through the Computer Center in order 
that the Computer Center will be able to keep 
track of these supplies. 

4. NOTTS software and all other applications 
software ordering will be responsibility of 
the Library 

5. Inform Computer Center of all changes (hardware/ 
software) to be made to the IBM 4 361 



B. University Computer Center 

1. House the IBM 4361 

2. Arrange for initial installation of the hardware 
and software and bring the system into a full 
operational status 

3. Arrange for continued maintenance of the hardware 
and software 

4. Provide operator coverage as needed and scheduled 
by the Library 
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II. BUDGET 

The Computer Center will establish a budget to track 
all expenditures directly associated with the operation 
of the Library IBM 4361 Computer System. This budget 
will be a fiscal year end zero balance budget with all 
expenditures being paid by the Library . The following 
costs- are associated with this budget. 

A. Staff Cost,s 

1. Operator Costs : initially to be charged at the 
rate of 1/4 of an operator for- 2-1/2 shifts 
including Saturday and Sunday at the rate of 
$12,000 per year salary and benefits: 

12 , 00 0/4x2 . 5=$7 , 500/year 

This is to be re-evaluated when the Library 
system goes on-line in the Fall. 

2. Continuing System Support : Estimated that this 
requirement will be equal to 1/4 of a system 
person per year, cost will equal $8,000 per year. 

B. Maintenance Hardware and Software 

1. The Computer Center will contract with IBM and 
other vendors for annual maintenance contract. 
These direct charges are to be billed to the 
Library. 

2. Items not under maintenance contract will be 
maintained by the Computer Center on a per-call 
basis with the vendor or by the Computer Center 
on a. time/material method estimated not to 
exceed $5 , 000/year . 

C. Supply Charges 

1. Ribbons, special forms, etc. 

D. Other Charges 

1. Physical space and facility charge based on 
Plant Operation square footage charges. 

2. Installation Charges. 
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III. SPECIAL REQUIREMENT 

It is required that Vanderbilt configure the NOTIS system 
to meet our requirements and to install the software onto 
the IBM 4361. It is estimated that this is a three to 
six man month effort. The Computer Center will provide 
the personnel to do this task and will charge the Library 
at the rate of $25 per hour. This charge will be in 
addition to the system support referred to in Section 
II. A. 2. 



Approved ; 




J/mes F. Petzii/dk 




Vanderbilt University 
Computer Center 



Jean and Alexander Heard 
Library ' 



Date; 
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NEV/ YORK UNIVEE^ITY LIBl^RIES 
GEAC ONLINE CATALOG 

This document contains a general description of NYU's online catalog, 
IJobcat. The catalog is manufactured and sold by Geac Computers 
International, a computer company based in Markham, Ontario. NYU 
helped Geac to design the catalog and has continued to work with Geac 
in inproving and developing the catalog further. 

When the catalog was in design one of the primary goals was to create 
a tool that would be at the same time easy to use and powerful. Thus 
it would.be able to serve a wide variety of libraries ranging from 
small to large and including both public and academic. The positive 
reactions of library patrons in many Geac catalog installations 
attest to the successful attainment of this goal. 

The catalog's popularity and usefulness to both staff and patrons 
have increased over time. In order to continue to add enhancements 
such as dial in access NYU has purchased a new, more powerful 
conputer to which the catalog will be transferred shortly. 

A description of the NYU catalog follows: 



CONTENTS OF CATALOG 

Bobcat contains nearly 450,000 records. Most are monographs but many 
serials, scores, sound recordings, and manuscript and archive records 
are also included. In the near future records for machine-readable 
data files will also be added. 

Serial holdings displayed. in Bobcat consist of the information 
contained in the Summary Holdings Statonent (MARC field 930) in the 
RLIN record. Coded notes have been "exploded," into understandably 
worded phrases. 

•7 

About 250,000 of Bobcat's records were converted from OCLC to RLIN 
format when NYU joined RLG and ceased to utilize OCLC. As of the 
official "opening" date, September 1983, the Bobcat data base 
consisted of these OCLC records and about 50,000 records created 
on RLIN. After an initial year of experimentation and stabilization 
the card catalog was closed in June 1984 and filing of new cards 
ceased with the exception of non-roman cards and records from other 
NYU libraries. Retrospective conversion, using Carollton Press's 
REMARC system, has begun and these records will be added to Bobcat. 

LOCATION AND PLACEMENT OF TERMINALS 

Terminals are supplied by Geac Computers; they are polled, block-mode 
terminals with either amber or green phosphor screens. There are two 
types of terminals in use: CRT plus simple typewriter-like keyboard 
terminals for patron use; CRT plus full ALA character keyboard set 
for staff. Bobcat terminals are located on every floor of Bobst 
Library with a large cluster of thirty in the main floor catalog area 
adjacent to the card catalog. There are also terminals hooked by 
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2400 baud dedicated phone lines in 5 remote locations and 2 locations 
utilize dial in access to the catalog as needed. At present over 100 
terminals are operational on the system. The exact number installed 
in each catalog area was determined by a queuing study. 

In Bobst Library most terminals are in "stand-up" mode, i.e., on high 
tables. We have noted that patrons do take the high stools used by 
staff working at the card catalog; they almost always prefer to sit 
while searching r so that we will be purchasing additional high stools 
for some of the stand-up terminals. Most terminals on different 
floors in the stack area are stand-up only. There are terminals 
available for disabled students as well. 

The availability of Bobcat terminals on all floors of the library and 
at each of the reference centers has had a positive impact on patrons 
and reference staff. For the first time they have access to the 
holdings of the library at many different physical locations. The 
catalog makes it possible for patrons to search for additional 
materials without having to return to the main floor catalog area. 
It allows staff to teach proper catalog use in many different 
locations r thus diversifying the responsibility which formerly rested 
mainly on the general reference department staff. The presence of 
terminals adjacent to their offices also makes the collection 
development activities of reference staff easier. 

SEARGHIMG 

The catalog r which is a menu-driven syston, leads users through a 
search one screen at a time. Each search screen contains examples of 
how a search should be typed as well as brief information pertaining 
to the specific type of search. Help screens, which are tailored to 
an^lify information given on the initial search screens , are clearly 
written and include additional examples. 

Types of searches 

1) String searches by Author (AUT) , Title (TIL), or Subject 
(SUB.) SUB searches use standard Library of Congress subject 
headings and local headings (if desired.) 

2) Keyword (KEY) searches for Authors (AUTK) , Title (TILK) or. 
Subject (SUBK) . All significant words included with the 
exception of stoplisted words. 

3) Number (NUM) searches for LC card number (LCN) r Call number 
(CAL)r ISBNr ISSNr or ISW^ (ISN) r Government document number 
(GOV), or Music publisher nixnnber (PUB). 

4) Linked Author-Title (A-T) search on a 4-4 key, i.e., first 4 
letters of author •s last name, first 4 letters of first word of 
title. This may be expanded to a 10-10 key. 

5) Boolean search - utilizes via the author, title, and subject 
keyv/ord indexes. Can do adjacency searching as well. Installed 
presently on twenty-one terminals at reference desks and staff 
areas in each of the libraries. 
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Both Keyword and Number searches are 2-ievel type searches, 
i.e., patron first asks to do keyword search or number search 
and then selects the kind of keyword or number search. 

Title index entries do not anit non-filing characters on the basis of 
the second indicator; a stoplist is used instead. This was done for 2 
reasons: many of our older records created on OCLC do not include 
that filing indicator, and often patrons do not recognize articles 
which begin titles (particularly in foreign language titles.) The 
stoplist contains very few words (basically The, An, etc.) so that 
foreign language titles which begin with articles such as "Die," "La," 
"Los" are filed under those articles. We plan to utilize a Geac 
program to insert proper indicators into records which lack them. We 
can then cease using stoplists for string indexes. 



Commands available at each point in the searching process are 
presented in a menu at the bottom of the screen. This menu contains 
from 2-8 cormiands although in fact additional commands might be valid 
at that time. It was felt that more menu choices would cut down on 
screen space for actual data and would also tend to confuse or 
overwhelm patrons. 

Five function keys are activated oh Bobcat terminals and facilitate 
use of the syston: Help, Advanced Help, Start Over, Previous Screen, 
End. Help invokes whichever help screen is appropriate to what the 
patron is involved in at that moment. Advanced Help includes 
information on command chaining or stacking, a speedier way of 
searching the catalog. Start Over returns the user to the search type 
selection menu. Previous Screen presents from 6-10 physical screens^ 
showing exactly what had been displayed before (although results from 
key\>X)rd searches cannot be retained in monory) . This function key is 
particularly useful to reference staff as they try to help explain the 
catalog's operation to patrons. End actually terminates the whole 
process and recalls the Introductory screen so that the is ready for 
the next patron. 

An interesting phenomenon, and one which attests to the ease of use of 
the catalog, is the fact that many patrons do not end their searches 
but instead walk away from the terminal. The fact that the next 
person can walk up, follow the instructions on the bottom of the 
screen and not have to start right from the Introductory screen shows 
that the catalog is self-explanatory. In studies done by NYU in 1984 
the majority patrons stated that they learned how to use the catalog 
by themselves, i.e., by following instructions on the screen. 



Great care was taken during the design stages to ensure that screens 
would not be too "cluttered" or verbose, and that jargon would not be 
used. The amount of data on each screen is generally in keeping with 
accepted formulae which state that only about 15% of the screen should 
contain information. Patrons have mentioned that the catalog is 
very easy to understand, so apparently efforts to devise simple, 
easily understandable screens were successful. 



COMMANDS 



DISPLAYS 
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There are 4 record displays available to patrons; these vary in 

gurpose from very brief for identification purposes to full 
ibliographic information for scholarly use. 

Index displays contain one line per record from a section of the index 
which matches the user's search. 

Citation displays present those entries associated with a particular 
index node^ e.g., all of an author's works; 

Brief display (DRF) - contains author^ title^ edition (if any) and 
imprint (full 260 field). Each field has a left-justified, upper 
case, lower intensity label. In addition, location, call number and 
copy number are included for every copy of the title. The location 
code consists of 6 or fewer characters, in upper case, the first of 
which represents the library where the item is located while the 
remaining letters tell where in that library the title is located. 
For example, BSTACK means the book is is Bobst Library in the main 
stacks. Status information is not yet included in the BRF display 
though this is planned for the future. 

Pull display (FUL) resembles an LC card in fullness of data, but has 
separate paragrajAis which are labelled as in the Brief display. For 
example, tracings are^grouped in paragraphs with labels such as "OTHER 
AUTHORS," "SUBJECTS," or "OTHER TITLES." The tracings are not 
preceded by numerals as on LC cards but are separated by a 
space-asterisk-space. Location information is not included on the FUL 
display; patrons who want this information must return to the BRF 
screen. This was done to prevent a large proportion of records from 
flowing onto a second screen. 

In addition to the four displays which the public' see there is a fully 
tagged MARC display for staff use. 

What is displayed in response to a search depends upon the kind of 
search done and what is retrieved. When a search retrieves an index 
entry which has only one record associated with it, that record is 
inmediately displayed in BRF format. When more than one index node is 
retrieved, an IND(ex) list results. When one index node with more 
than one record is retrieved, then the patron is shown a CIT(ation) 
list. 

AIDS TO USERS 

If a searcher types an "incorrect" or unrecognizable comnand the 
system "answers" with a clearly worded, non- judgmental error message. 
The user can press the HELP key to get explanatory information. If 
the same mistake is made three times, at the third occurrence the user 
"strikes out," and the system automatically presents the help screen. 
There is also an Advanced Help screen explaining the use of comnarjd 
chaining, a speedier way of searching than the menu-driven approach. 

If a search finds no match, the user is given several helpful pieces 
of information or hints: the search as input is redisplayed on the 
screen, a message states that the search found no matches, and a 
portion of the index is displayed beginning with those entries which 
alphabetically iimiediately precede and follow the search as entered. 
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Itie patron can thus check for typographical errors, and/or scan the 
inc3ex display for other possibly useful entries. The index display 
often serves as a visual clue that something was mistyped, e.g., the 
display shows words beginning with the letter K rather than L. 

Bobcat Bulletins which contain general information about the catalog 
are widely available. They include information on the catalog's 
holdings, a list of commands, library location abbreviations (along 
with full location names) and helpful hints. These Bulletins are on 2 
sided, 8 l/2"xll" gold paper topped by the Bobcat logo, a grinning 
Bobcat in an NYU tee shirt. The Bulletins are pasted under plastic 
sheets on the tables next to the terminals. 

There is a series of Bobcat Bulletins for staff (on green paper) 
which is not circulated to the public. 

To inform users of the necessity of consulting the card catalog 
plastic strips with white letters on a black background have been 
pasted above and below terminal screens. They bear the legend "Bobcat 
does not have it all." [above screen] "Check the card catalog 
too." [below screen] or "Bobcat contains only part of our 
holdings." [above screen] "Please check. the card catalog." [below 
screen] (Unfortunately, patrons seem to ignore these signs and often 
assume that Bobcat is complete.) 

FEATURES TO BE IMPLEMENTED IN FUTURE 

There are still a number of enhancements to the online catalog which 
are not yet implemented. They will be installed as Geac makes them 
available or as NYU is ready: 

1. Authority control which is already available will be implemented 
soon. This will aid enormously in bringing together the separate 
files caused by AACRl versus AACR2 forms of heading, in correcting 
typographical errors, and in enhancing all future changes to catalog 
headings. It will also enable patrons to automatically see the proper 
form of heading without forcing them to retype their search. 

2. Printing from the catalog is available; NYU is in the process of 
deciding whether to use individual printers at terminals for screen 
dumps or one high-speed printer at a central location (and a charge 
for printouts.) We also hope to incorporate a save file to allow 
users to retain records and sort them in any order before printing. 

3. Scanning through indexes and citation lists should be enhanced. 
Although one can scan FOR (ward) or BAC(kward) through such lists now, 
it is not possible to junp a specified number of entries in either 
direction. 

5. Displaying records for a specific location is not posssible 

at present. Searches currently call up matching holdings from the 
union data base. This will be corrected in the next release of the 
software as well as on the 9000 system. 

6. Dial access to Bobcat will be implemented "with the move to the 9000 
system. This will be on an experimental basis at first with only a 
few ports. 
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7. On order and in process information will be incorporated into 
Bobcat to notify staff and patrons of materials which have not yet 
been cataloged and added to the permanent data base. 

8. Status information will appear as part of the Diy? display when the 
circulation and online catalog data bases are matched against each 
other . 

9. Boolean searching will be expanded to all terminals rather than 
limited to reference desks. NYU staff have sent Geac a set of revised 
screens and suggestions for improvements to Boolean searching. 

10. Reserve reading information will be listed in the online catalog 
rather than in printed lists. 

aut352 (based on autll4) 

5.24.84 revised 5.24.85 revised 4.10.86 

g. per sky 
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COMPLETE TRANSACTION STATISTICS 

TRANSACTION 
"■ DESCRIPTION 



NUMBER PERCENT 
SEARCHES 



B5-U-19 15:29:94 PAGE 139 

PERCENT 
OF TOTAL 



TITLE SEARCH:'"- 
AUTHOR SEARCH: 
AUTHOR-TITLE SEARCH: 

SUBJECT SEARCH: 

TITLE KEYWORD SEARCH: 
AUTHOR KEYWORD SEARCH: 
SUBJECT KEYWORD' SEARCH: - 
BOOLEAN SEARCH: 
ISN NUMBER SEARCH: 

LCN NUMBER SEARCH: 

GOV NUMBER SEARCH: 
CSN NUMBER SEARCH: 

PUB- NUMBER- SEARCH:' 

CALL NUMBER SEARCH: 



TIL~ 
AUT 
A-T 
■SUB-- 
TILK 
AUTK 
SUBK- 
BOL 
ISN 
LCN" 
GOV 
CSN 
PUB- 
CAL 



Tm SEARCHES.- ALL-TERMINALSr 



NUMBER SEARCHrr 
KEYWORD SEARCH:' 



NUM" 
KEY 



SEARCH-ALL- AGENCIES: 

SEARCH THIS AGENCY ONLY: 
REQUEST FOR HELP: 

REQUEST- FOR-ADVANCED- HELP: 

REQUEST FOR BRIEF DISPLAY: 
REQUEST FOR FULL DISPLAY: 
REQUEST FOR- INDEX- DISPLAY:— 
REQUEST FOR CITATION DISPLAY: 
MOVE FORWARD IN DISPLAY: 
MOVE BACKWARD-IN-DISPLAY: 



RETURN TO PREVIOUS SCREEN: 

RETURN TO CAT: 

END- SESSION: 



-ALL- 
LIB 
HLP 
-AVH- 
BRF 
FUL 
-IND- 
CIT 
FOR 
-BAC- 
PREV 
CAT 
END- 



OVERALL TOTALS, ALL TERMINALS: 



"1 



S61' 
937 
191 
739 ■ 
62 
6 

-76 
29 
4 

0- 

0 

2 

-Q- 
96 



■2i 999- 



"lOQ- 
153 



-3" 
0 

93 

-82- 
219 
870 
150- 
146 
3.152 
-889- 
743 
2.271 
•- 168- 



23.7 
31.2 
6.4 
24.6 
2.1 
0.2 

■ 2.5 
0.8 
0.1 

■ 0.0- 
0.0 
0.1 

"0.0 
3.2 



6.6 
7.2 

1.5 
5.7 
0.9 
0.0 
0.6 
0.2 
0.0 
0.0 
0.0 
0.0 
0.0 
0.7 



0.8 
1.2 



sin Sl-lil 



Ktiji^irl uJ yt*^ ^^^^^^ 
if i\ ()lv«:i^fffc^t;-■ 



....^ 

< 

■n 
g 

A 

....-4 

H 
< 



0.0 --• 

0.0 
0.7 

- 0.6 - 

1.7 
6.7 

. g^g . ^ _ 

1.1 

24.2 «^ Coirtjj ^itrw ividU \\ih 
6,8 iMj.'*MnMA"' jc^K^ajlOh — :.. 



13. 038 



5.7 0^ Oi-ht'^ s;urc/«kj, 

7«4 S(k^j rf t#nr^ ^ l)i|p<\ti 

1'3 4l\ii 6ow»i^>\J n.l+o^lkr 

- <3t..w»H.lA.S.-.. . 
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VANDERBILT UNIVERSITY 

USE STATISTICS 



VHien you're in Che Library and need Co use a catalog, are you more likely to 



use • • 







Total 


Total 


Total 


Undergrads 






Sample 


Students 


Ugrads 


Male 


Fema 


A card catalog 


137 


115 




53 


46 






23Z 


28% 


27% 


23% 


35% 


Computerized catalog 


203 


185 


165 


113 


52 






AlZ 


45% 


45% 


48% 


39% 


Either - 


Doesn't really 73 


58 


50 


32 


18 


matter 




15% 


14% 


14% 


14% 


14% 


I don't use catalogs 


26 


21 


20 


12 


8 






5Z 


5% 


5% 


5% 


6% 


Don't know 


51 


3 7 


34 




Q 






10% 


9% 


y /» 


1 LA 


/A 


Public Catalog Use Statistics 










Count of 


searches by 


type of search 












December 


(16 davs) 


February 


(21 davs; 






Author 


8,231 


32% 


13,217 




30% 




Subject Ic 


8,963 


35% 


16,242 




3 7% 




Subjectm 


589 


2% 


1 ,230 




3% 




Title 


7,978 


31% 


13,351 




30% 




Count of 


se<:-.ches by 


number of hits 












December 


(16 days) 


February 


(21 days) 






0 


9,287 


36% 


1 C ft O "7 

15,987 








1 


2,82A 


11% 


4 , Do2 




1 f\f 

10% 




2-17 


7,130 


28% 


1 1 ,920 




27% 




* 8-34 


1,7A0 


7% 


2,974 




7% 




35-51 


883 


3% 


1,512 




3% 




52-68 


548 


2% 


903 




2Z 




69-998 


2,957 


11% 


D ,4 09 




12% 




999-9999 


392 


2% 


776 




2% 






Novembe r 


December 




Feb ruary 






Help 












screens 


893 


1,238 




1,980 






displayed 














Intro 














screens 


2,058 


2.349 




4,566 






displayed 














Searches 


18,168 


25,761 




44,043 
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